[uClinux-dev] The Power of 2

Greg Ungerer gerg at snapgear.com
Sun Oct 16 08:19:35 EDT 2005


Hi Robin,

Robin Getz wrote:
> I was poking around looking at where stack was, when an end user was 
> discussing what they thought was a stack problem (it wasn't), and 
> noticed that between the BSS section, and the end of stack, there was a 
> large gap - depending on the size of the application.
> 
> Here are some examples.
> 
> APP      size   TEXT     DATA        BSS         GAP      STACK       MEM
> -------- ------ -------- ----------- ----------- -------- ----------- -----
> uname     1928  44-  584   588-  668   668-  698 ( 2280d)   f80- 1ffc (  
> 8k)
> version  16068  44- 35a4  35a8- 3be8  3be8- 4c08 ( 9083d)  6f83- 7ffc ( 
> 32k)
> ifconfig 57796  44- 9fa4  9fa8- cca8  cca8- f118 (65129d) 1ef81-1fffc 
> (132k)
> dhcpcd   69648  44- ca84  ca88- f4d8  f4d8-12c38 (49997d) 1ef85-1fffc 
> (132k)
> thdm     84816  44- d184  d188-131a8 131a8-175e8 (31137d) 1ef89-1fffc 
> (132k)
> 
> size is size in the ramfs
> TEXT is the location of the text section
> DATA is the location of the data section
> BSS  is the location of the bss section
> GAP  is the size of the gap between the end of the BSS section, and the 
> end of the stack.
> STACK is the location of the stack.
> MEM  is the memory footprint in the system.
> All values in hex, except GAP and MEM.
> 
> Loading up an application like ifconfig, where there is a 64k gap is 
> kind of silly in an embedded application, where memory is a precious 
> resource.

Indeed it is. That is why Davidm developed kmalloc2.


> I figured out this must be the power of 2 allocator in the kernel, and 
> went looking for page_alloc2 or kmalloc2 per David McCullough's article at:
> http://new.linuxjournal.com/article/7221

It is. It is fairly easy to see that is the case. Look at where BSS
ends, add the minimum 4k default stack and you can see that each of
ifconfig/dhcpcd/thdm are larger than 64k, so the next logical power
of 2 block size if 128k (0x20000) - and that is what kmalloc is
giving you.


> But I could not find them. I found versions for the 2.4
> http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-2.4.x/mmnommu/
> 
> Any pointers to where what to do for the 2.6 kernel? This seemed to be 
> in some linux 2.5.44-ac trees, but not in 2.5.45 Can anyone who was 
> paying attention provide any history?

Nobody ever really carried it forward from the 2.4 kernels.
I don't recall anybody using it with even the early in the
2.5 series. I doubt it has ever worked with anything newer
after the move up from 2.4 kernels.


> Thanks
> -Robin
> 
> BTW - I also noticed in linux-2.6.x/fs/binfmt_flat.c
> 
>         /* zero the BSS,  BRK and stack areas */
>         memset((void*)(datapos + data_len), 0, bss_len +
>                         (memp + ksize((void *) memp) - stack_len -      
> /* end brk */
>                         libinfo->lib_list[id].start_brk) +              
> /* start brk */
>                         stack_len);
> 
> Why does the BRK (the GAP), and stack need to be cleared to zero?

On a VM system it would be security (you don't want apps
to be able to read contents of other programs lying around in memory).
Not quite so usefull without VM :-)

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com



More information about the uClinux-dev mailing list