[uClinux-dev] Stack size relation to memory use
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
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
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
Re: [uClinux-dev] [PATCH 6/7] ld-elf2flt: convert to C
Jivin Mike Frysinger lays it down ... On Tue, Jul 7, 2009 at 06:43, David McCullough wrote: Jivin Mike Frysinger lays it down ... Due to shell portability issues (which is to say shell scripts are not portable -- think Windows), convert elf2flt to C code. I've updated this code base to the latest elf2flt tree and actually done some basic tests -- building the three Blackfin tuples (ELF, FLAT, FDPIC) and running programs on my Blackfin boards. This process found errors in the original implementation as well as some of the cleanups I did. Signed-off-by: Nathan Sidwell nat...@codesourcery.com Signed-off-by: Mike Frysinger vap...@gentoo.org Rather than rename ld-elf2flt.in I merged dropped patch 4 and made some changes to patch 6 and fixed a logic error with the configure use_ld_elf2flt_script logic so that it is not inverted. Try this patch against current CVS and see if it's ok for you, the reason i liked renaming ld-elf2flt script to .sh is that you could run configure by default and end up with both the binary and the shell script. if something was wonky, this lets you quickly test either one without having to re-run configure to switch modes. i'm not terribly set on keeping this functionality, just pointing out that it was done this way on purpose. And some of why I didn't rename it is just leaving the CVS history die with the original file. Of course the rename to ld-elf2flt.in probably ate that already :-( I just figured that this will be mostly temporary and that the script will get dropped due to being defaulted to off and bit rotting and . at any rate, in the process of fixing my inverted logic, it looks like some were left behind. you'll want to drop the AC_SUBST() right after the AC_ARG_ENABLE(): +AC_SUBST(use_ld_elf2flt_script) and then at the end, you used the _script instead of the _binary: +if test $use_ld_elf2flt_script = yes ; then +AC_OUTPUT(ld-elf2flt) +fi Yep, thanks, I didn't quite get back to figuring out why it only built ld-elf2flt (the script) at build time and not at configure time ;-) So I think what I have ready to commit is good to go. Haven't seen any comments strongly against it, so later today or tomorrow I'll check it in, 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
Re: [uClinux-dev] [PATCH 6/7] ld-elf2flt: convert to C
On Wednesday 08 July 2009 20:56:20 David McCullough wrote: Jivin Mike Frysinger lays it down ... On Tue, Jul 7, 2009 at 06:43, David McCullough wrote: Jivin Mike Frysinger lays it down ... Due to shell portability issues (which is to say shell scripts are not portable -- think Windows), convert elf2flt to C code. I've updated this code base to the latest elf2flt tree and actually done some basic tests -- building the three Blackfin tuples (ELF, FLAT, FDPIC) and running programs on my Blackfin boards. This process found errors in the original implementation as well as some of the cleanups I did. Signed-off-by: Nathan Sidwell nat...@codesourcery.com Signed-off-by: Mike Frysinger vap...@gentoo.org Rather than rename ld-elf2flt.in I merged dropped patch 4 and made some changes to patch 6 and fixed a logic error with the configure use_ld_elf2flt_script logic so that it is not inverted. Try this patch against current CVS and see if it's ok for you, the reason i liked renaming ld-elf2flt script to .sh is that you could run configure by default and end up with both the binary and the shell script. if something was wonky, this lets you quickly test either one without having to re-run configure to switch modes. i'm not terribly set on keeping this functionality, just pointing out that it was done this way on purpose. And some of why I didn't rename it is just leaving the CVS history die with the original file. Of course the rename to ld-elf2flt.in probably ate that already :-( ah, that does suck. time to move to git ! :) I just figured that this will be mostly temporary and that the script will get dropped due to being defaulted to off and bit rotting and . hmm, i'd forgotten about an oft unused config.status feature ... how about adding a dedicated rule that looks like: ld-elf2flt.sh: $(srcdir)/ld-elf2flt.in ./config.status --file=$@:$ this would allow people debugging things to manually run `make ld-elf2flt.sh` and get the right thing -mike signature.asc Description: This is a digitally signed message part. ___ 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] [PATCH 6/7] ld-elf2flt: convert to C
Jivin Mike Frysinger lays it down ... On Wednesday 08 July 2009 20:56:20 David McCullough wrote: Jivin Mike Frysinger lays it down ... On Tue, Jul 7, 2009 at 06:43, David McCullough wrote: Jivin Mike Frysinger lays it down ... Due to shell portability issues (which is to say shell scripts are not portable -- think Windows), convert elf2flt to C code. I've updated this code base to the latest elf2flt tree and actually done some basic tests -- building the three Blackfin tuples (ELF, FLAT, FDPIC) and running programs on my Blackfin boards. This process found errors in the original implementation as well as some of the cleanups I did. Signed-off-by: Nathan Sidwell nat...@codesourcery.com Signed-off-by: Mike Frysinger vap...@gentoo.org Rather than rename ld-elf2flt.in I merged dropped patch 4 and made some changes to patch 6 and fixed a logic error with the configure use_ld_elf2flt_script logic so that it is not inverted. Try this patch against current CVS and see if it's ok for you, the reason i liked renaming ld-elf2flt script to .sh is that you could run configure by default and end up with both the binary and the shell script. if something was wonky, this lets you quickly test either one without having to re-run configure to switch modes. i'm not terribly set on keeping this functionality, just pointing out that it was done this way on purpose. And some of why I didn't rename it is just leaving the CVS history die with the original file. Of course the rename to ld-elf2flt.in probably ate that already :-( ah, that does suck. time to move to git ! :) I just figured that this will be mostly temporary and that the script will get dropped due to being defaulted to off and bit rotting and . hmm, i'd forgotten about an oft unused config.status feature ... how about adding a dedicated rule that looks like: ld-elf2flt.sh: $(srcdir)/ld-elf2flt.in ./config.status --file=$@:$ this would allow people debugging things to manually run `make ld-elf2flt.sh` and get the right thing Even better :-) AC_OUTPUT(ld-elf2flt.sh:ld-elf2flt.in Makefile elf2flt.ld) lets us keep the old name and generate both all the time, with other fixups of course. We can work out what I have missed once it's committed ;-) 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
