Shared memory

QNX Newsgroups (Archives) qdn.public.qnx4
1

Hi,

I am using QNX 4.25 running on Compaq with 1 GB memory. I have over 200
processes running on this machine with a 20 MB of shared memory used by all
the processes. Recently I cannot add any new process because the mmap
returns ENOMEM. I suspect that I have run out of virtual memory because
sin -info shows Virtual 225M/4206M. /dev/shmem/Physical size is 4294963200.
Looks like QNX has all processes sharing the same virtual memory address
space. Is there any solution to increase the virtual memory? or to make each
process has its own virtual address space of 4 GB? I still have over half GB
of physical memory available in the system.

Regards.
Johannes

2

Previously, Johannes wrote in qdn.public.qnx4:

I am using QNX 4.25 running on Compaq with 1 GB memory. I have over 200
processes running on this machine with a 20 MB of shared memory used by all
the processes. Recently I cannot add any new process because the mmap
returns ENOMEM. I suspect that I have run out of virtual memory because
sin -info shows Virtual 225M/4206M.

It could be some Proc table has filled up. 200 sounds like a lot of processes
to be running in 20Meg unless most of them are quite small.

.dev/shmem/Physical size is 4294963200.
Looks like QNX has all processes sharing the same virtual memory address
space.

Don’t be fooled. This has nothing to do with the actual memory size.
This is just your access to anywhere in real “Physical” memory.

Is there any solution to increase the virtual memory?

Like I say, there’s probably some table in Proc filled up. Take
a look at the Proc documentation to see if there’s an obvious
parameter.

or to make each
process has its own virtual address space of 4 GB? I still have over half GB
of physical memory available in the system.

This is already the case. Virtual memory does not take up any room except
for LDT, GDT tables, and page tables. Come to think of it, this could
be a page table problem.

Mitchell Schoenbrun --------- maschoen@pobox.com

3

Try running osinfo to see what Proc resource has filled up.

Bill Caroselli

“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.010821225340.196E@schoenbrun.com…

Previously, Johannes wrote in qdn.public.qnx4:

I am using QNX 4.25 running on Compaq with 1 GB memory. I have over 200
processes running on this machine with a 20 MB of shared memory used by
all
the processes. Recently I cannot add any new process because the mmap
returns ENOMEM. I suspect that I have run out of virtual memory because
sin -info shows Virtual 225M/4206M.

It could be some Proc table has filled up. 200 sounds like a lot of
processes
to be running in 20Meg unless most of them are quite small.

.dev/shmem/Physical size is 4294963200.
Looks like QNX has all processes sharing the same virtual memory address
space.

Don’t be fooled. This has nothing to do with the actual memory size.
This is just your access to anywhere in real “Physical” memory.

Is there any solution to increase the virtual memory?

Like I say, there’s probably some table in Proc filled up. Take
a look at the Proc documentation to see if there’s an obvious
parameter.

or to make each
process has its own virtual address space of 4 GB? I still have over
half GB
of physical memory available in the system.

This is already the case. Virtual memory does not take up any room
except
for LDT, GDT tables, and page tables. Come to think of it, this could
be a page table problem.

Mitchell Schoenbrun --------- > maschoen@pobox.com

4

osinfo won’t show problems with the LDT & GDT. Try goosing the
-S option to Proc to numbers like -S 500 5000 (I don’t know a
scientific way to determine these).


“Bill Caroselli (Q-TPS)” wrote:

Try running osinfo to see what Proc resource has filled up.

Bill Caroselli

“Mitchell Schoenbrun” <> maschoen@pobox.com> > wrote in message
news:> Voyager.010821225340.196E@schoenbrun.com> …
Previously, Johannes wrote in qdn.public.qnx4:

I am using QNX 4.25 running on Compaq with 1 GB memory. I have over 200
processes running on this machine with a 20 MB of shared memory used by
all
the processes. Recently I cannot add any new process because the mmap
returns ENOMEM. I suspect that I have run out of virtual memory because
sin -info shows Virtual 225M/4206M.

It could be some Proc table has filled up. 200 sounds like a lot of
processes
to be running in 20Meg unless most of them are quite small.

.dev/shmem/Physical size is 4294963200.
Looks like QNX has all processes sharing the same virtual memory address
space.

Don’t be fooled. This has nothing to do with the actual memory size.
This is just your access to anywhere in real “Physical” memory.

Is there any solution to increase the virtual memory?

Like I say, there’s probably some table in Proc filled up. Take
a look at the Proc documentation to see if there’s an obvious
parameter.

or to make each
process has its own virtual address space of 4 GB? I still have over
half GB
of physical memory available in the system.

This is already the case. Virtual memory does not take up any room
except
for LDT, GDT tables, and page tables. Come to think of it, this could
be a page table problem.

Mitchell Schoenbrun --------- > maschoen@pobox.com

5

I have tried the -S 10000 5000 option to Proc but it doesn’t make any
different.

Everytime when I run a new process, I notice that the amount of Virtual
memory available (shown in sin info) has decreased as much as 20MB, which
means that sooner or later the system will run out of Virtual memory which
is limited to 4 GB, as I run more processes of the same kind. Am I right
about this limitation in QNX?

If I were right about the virtual memory, is it possible for me to mmap the
shared memory such that it does not consume any virtual memory at all?

“Richard R. Kramer” <rrkramer@kramer-smilko.com> wrote in message
news:3B8441AD.8248C02C@kramer-smilko.com…

osinfo won’t show problems with the LDT & GDT. Try goosing the
-S option to Proc to numbers like -S 500 5000 (I don’t know a
scientific way to determine these).


“Bill Caroselli (Q-TPS)” wrote:

Try running osinfo to see what Proc resource has filled up.

Bill Caroselli

“Mitchell Schoenbrun” <> maschoen@pobox.com> > wrote in message
news:> Voyager.010821225340.196E@schoenbrun.com> …
Previously, Johannes wrote in qdn.public.qnx4:

I am using QNX 4.25 running on Compaq with 1 GB memory. I have over
200
processes running on this machine with a 20 MB of shared memory used
by
all
the processes. Recently I cannot add any new process because the
mmap
returns ENOMEM. I suspect that I have run out of virtual memory
because
sin -info shows Virtual 225M/4206M.

It could be some Proc table has filled up. 200 sounds like a lot of
processes
to be running in 20Meg unless most of them are quite small.

.dev/shmem/Physical size is 4294963200.
Looks like QNX has all processes sharing the same virtual memory
address
space.

Don’t be fooled. This has nothing to do with the actual memory size.
This is just your access to anywhere in real “Physical” memory.

Is there any solution to increase the virtual memory?

Like I say, there’s probably some table in Proc filled up. Take
a look at the Proc documentation to see if there’s an obvious
parameter.

or to make each
process has its own virtual address space of 4 GB? I still have over
half GB
of physical memory available in the system.

This is already the case. Virtual memory does not take up any room
except
for LDT, GDT tables, and page tables. Come to think of it, this could
be a page table problem.

Mitchell Schoenbrun --------- > maschoen@pobox.com

6

I have tried the -S 10000 5000 option to Proc but it doesn’t make any
different.

Everytime when I run a new process, I notice that the amount of Virtual
memory available (shown in sin info) has decreased as much as 20MB, which
means that sooner or later the system will run out of Virtual memory which
is limited to 4 GB, as I run more processes of the same kind. Am I right
about this limitation in QNX?

If I were right about the virtual memory, is it possible for me to mmap the
shared memory such that it does not consume any virtual memory at all?

“Richard R. Kramer” <rrkramer@kramer-smilko.com> wrote in message
news:3B8441AD.8248C02C@kramer-smilko.com…

osinfo won’t show problems with the LDT & GDT. Try goosing the
-S option to Proc to numbers like -S 500 5000 (I don’t know a
scientific way to determine these).


“Bill Caroselli (Q-TPS)” wrote:

Try running osinfo to see what Proc resource has filled up.

Bill Caroselli

“Mitchell Schoenbrun” <> maschoen@pobox.com> > wrote in message
news:> Voyager.010821225340.196E@schoenbrun.com> …
Previously, Johannes wrote in qdn.public.qnx4:

I am using QNX 4.25 running on Compaq with 1 GB memory. I have over
200
processes running on this machine with a 20 MB of shared memory used
by
all
the processes. Recently I cannot add any new process because the
mmap
returns ENOMEM. I suspect that I have run out of virtual memory
because
sin -info shows Virtual 225M/4206M.

It could be some Proc table has filled up. 200 sounds like a lot of
processes
to be running in 20Meg unless most of them are quite small.

.dev/shmem/Physical size is 4294963200.
Looks like QNX has all processes sharing the same virtual memory
address
space.

Don’t be fooled. This has nothing to do with the actual memory size.
This is just your access to anywhere in real “Physical” memory.

Is there any solution to increase the virtual memory?

Like I say, there’s probably some table in Proc filled up. Take
a look at the Proc documentation to see if there’s an obvious
parameter.

or to make each
process has its own virtual address space of 4 GB? I still have over
half GB
of physical memory available in the system.

This is already the case. Virtual memory does not take up any room
except
for LDT, GDT tables, and page tables. Come to think of it, this could
be a page table problem.

Mitchell Schoenbrun --------- > maschoen@pobox.com

7

That’s funny, I am working on a ramtrap issue right now. I have noticed
that when I use it (ramtrap -q add), I get a huge increase in the amount of
Virtual RAM. You may want to try it.

David de Leon
Command Alkon Corp.