willem ha scritto:
well I made 10 copy's of threadbug and run them in parallel. In my
case libpthread does not allocate a 10 Mb memory block, because
the 10 processes should allocate 100Mb of memory Top does show only
a sligth increase in memory . On my kubuntu there are
145 processes allocated . So i can not reproduce your problem.
Well, virtual memory administration is a bit more elaborate than Top
totals can show.
I suggest you reading:
http://www.redhat.com/magazine/001nov04/features/vm/
to have a general idea.
A request for memory allocation just provides an entry in the virtual
memory table, without any physical counterpart. That's why you may
enable the kernel to over commit (see overcommit_memory and
overcommit_ratio in the above article), i.e. to accept allocation
requests for more memory than available (RAM size + swap size). That
can be done if you know for sure that many of your processes allocate
more memory than they'll actually use.
Allocated memory becomes physical memory only when an attempt to
access it is performed, care of MMU unit. And only at this stage Top
totals shows it.
But unless you've set (temerarily) your kernel parameters otherwise,
when the total of allocation requests exceeds the available physical
space, further requests are rejected. So you may have Top reporting
800Mb free, and your application terminated with an out of memory
error, when requesting the allocation of 10 Mb.
I've modified threadbug to activate many threads instead if just one.
I show you the results with 300 threads.
Thats Top report when threadbug is started:
top - 11:56:33 up 37 min, 6 users, load average: 0.33, 0.16, 0.11
Tasks: 127 total, 1 running, 126 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.8%us, 0.2%sy, 0.0%ni, 98.8%id, 0.0%wa, 0.2%hi,
0.0%si, 0.0%st
Mem: 1024940k total, 496500k used, 528440k free, 22416k buffers
Swap: 1028152k total, 0k used, 1028152k free, 312576k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4227 colla 17 0 2548 788 488 S 0 0.1 0:00.00 threadbug
That's the output of Top after 300 threads have been activated:
top - 12:00:48 up 42 min, 6 users, load average: 0.30, 0.26, 0.16
Tasks: 127 total, 1 running, 126 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.5%us, 0.2%sy, 0.0%ni, 98.3%id, 0.0%wa, 0.0%hi,
0.0%si, 0.0%st
Mem: 1024940k total, 501224k used, 523716k free, 22664k buffers
Swap: 1028152k total, 0k used, 1028152k free, 312708k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4227 colla 24 0 3004m 3300 520 S 0 0.3 0:00.08 threadbug
You can see that memory usage has minimally changed, from 496500k to
501224, but you can also see that the virtual memory allocated to
threadbug has jumped from 2548k to 3004m (i.e. 3Gb!).
That's Top output after the 300 threads have been destroyed:
top - 12:15:55 up 57 min, 6 users, load average: 0.55, 2.65, 2.12
Tasks: 127 total, 2 running, 125 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.5%us, 0.2%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi,
0.0%si, 0.0%st
Mem: 1024940k total, 535096k used, 489844k free, 24288k buffers
Swap: 1028152k total, 0k used, 1028152k free, 334308k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4227 colla 15 0 33364 988 576 S 0 0.1 0:01.20 threadbug
You can see that total memory usage has increased instead of
decreasing, because some allocated memory has been actually used, but
what's more important, you can see that virtual memory allocated to
threadbug is 33364 kB instead of the initial 2254.
Do you obtain different results?
Giuliano
Please send your modified threadbug program , so that i can compare
the results on my system.
