[uClinux-dev] Stack size relation to memory use

2009-07-08 Thread Jan Ringoš

Hi everyone,

I was investigating why some of my processes use too much memory than 
expected (just by looking at /proc/pid/status), and found interesting 
relation to stack size (set with elf2flt). I prefer to use stack wherever 
possible instead of dynamic allocations for speed and to decrease potential 
for memory leaks, but the numbers below somewhat confused me.


If I leave the stack at 4 kB, the memory usage is 40 kB for this particluar 
program.

If I increase it to 32 kB, the memory usage jumps up to 250 kB or so.
I also tried to use 128 kB high stack, then the memory use happened to be 
over 500 kB.


In /proc/pid/maps I see that the most of this memory is single large mapped 
block.

How can 28 kB of stack increase result in 200 kB of memory more being used?
Or am I completely missing something else?

Thank you,

---
Jan Ringoš, j...@ringos.cz
www.ringos.cz, tringi.mx-3.cz


___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


Re: [uClinux-dev] Stack size relation to memory use

2009-07-08 Thread Jan Ringoš

From: Daniel Glöckner daniel...@gmx.net

On Wed, Jul 08, 2009 at 09:12:20PM +0200, Jan Ringoš wrote:
In /proc/pid/maps I see that the most of this memory is single large 
mapped

block.
How can 28 kB of stack increase result in 200 kB of memory more being 
used?

Or am I completely missing something else?


You don't happen to be using a kernel without this patch?:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0f3e442a403a344a5d0a49af9ecd7632b7e7343a

 Daniel


Hi Daniel,

the device I use runs uClinux built on Feb 25, 2008, so it is definitely 
without this patch. And without many others probably. Unfortunatelly, as the 
device is from third party, I am not able to build or upgrade the kernel.


Do I understand it right that the unpatched version just expands the stack 
length to fill into the actuall size of allocated memory, and even if it 
didn't the memory couldn't be used anyway? If so... how can I get the actual 
stack size? Or what at all can I do, to approach certain stack size? ...4 kB 
is too little, but 200 kB is way too much.


---
Jan Ringoš, j...@ringos.cz
www.ringos.cz, tringi.mx-3.cz

___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


Re: [uClinux-dev] Stack size relation to memory use

2009-07-08 Thread David McCullough

Jivin Jan Ringoš lays it down ...
 Hi everyone,

 I was investigating why some of my processes use too much memory than  
 expected (just by looking at /proc/pid/status), and found interesting  
 relation to stack size (set with elf2flt). I prefer to use stack wherever 
 possible instead of dynamic allocations for speed and to decrease 
 potential for memory leaks, but the numbers below somewhat confused me.

On a !MMU system,  using the stack is not such a good idea IMO. 
The stack is fixed and must be allocated. Having a large stack just to cope
with a config file parse or some other temporary use is just wasteful
and forces you applications runtime memory usage to be higher than needed.

 If I leave the stack at 4 kB, the memory usage is 40 kB for this 
 particluar program.
 If I increase it to 32 kB, the memory usage jumps up to 250 kB or so.
 I also tried to use 128 kB high stack, then the memory use happened to be 
 over 500 kB.

 In /proc/pid/maps I see that the most of this memory is single large 
 mapped block.
 How can 28 kB of stack increase result in 200 kB of memory more being used?
 Or am I completely missing something else?

Sounds like you are using a power-of-2 allocator in your kernel.

Take all your sizes,  add them together then round up to the next power-of-2
to get the minimum size you will allocate.

Though that doesn't quite add up in this case though,  but it will get you a
lot closer.

Cheers,
Davidm

-- 
David McCullough,  david_mccullo...@securecomputing.com,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.comhttp://www.uCdot.org
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev