[uClinux-dev] How to know what's taking place in memory

David McCullough davidm at snapgear.com
Tue Nov 27 21:34:52 EST 2001

Jivin Fabrice Gautier lays it down ...
> > -----Original Message-----
> > From: David McCullough [mailto:davidm at snapgear.com]
> > Subject: Re: [uClinux-dev] How to know what's taking place in memory
> > 
> > > At the beggining I have this message:
> > > Memory: 1MB = 1MB total
> > > Memory: 304KB available (388K code, 150K data, 28K init)
> > > 
> > > If I do 304 + 388 + 150 + 28, i'm far from the 1mb total. 
> > What does thsi
> > > figures really mean?
> > 
> > 
> > These sizes are raw,  not operational size. I am not 100% but 
> > I would think
> > that the rest is lost to runtime memory allocation by the kernel.
> > 
> > Do you have you romfs in ROM or RAM ?
> In RAM. Actually i have a 2.0.x kernel on ROM, and running on ROM, and the
> same line report code = 0K. So this would sure free some mem to have it in
> ROM.

Depending on how this is accounted for may explain why the numbers don't
add up.

> > > This mean that some part of the kernel is allocating and 
> > freeing memory
> > > before init.
> > 
> > Quite possible.  Any kernel threads will allocate memory for the task
> > structures etc.  Some drivers may allocate memory when they startup.
> But which one would free something soon after? The only thing i can think of
> that would fragment the memory would be the init segment which is freed at
> some time, but that's 28k 

Network traffic maybe ?  You also have to rememeber that the way the kernel
divides up the memory is subject to power of 2 restrictions,  so it may
appear fragmented when it isn't.  It will also split up a higher order of 2
to get memory to fill smaller requests.

So if you run out of 8K blocks,  if will take from a 16K block if one is
free,  and will keep walking up the orders until is finds some space.

> > The easiest way if you have a debugger will be to stop on kmalloc and
> > page_alloc routines and see who is calling them during 
> > startup,  and how
> > much they are using.  You may find someone who can be reduced.
> Yes, but BTW how do people usually debug kernel on that kind of case? Right
> no i'm using the ARM debugger with multiICE trought the JTAG interface of
> the board. Unfortunately a bug in this debugger make it impossible to have a
> call stack of functions so this is quite difficult.

I must have it easy,  we use gdb through a bdm interface,  everything
works :-)

You could trace it by hand but that is just painful,  otherwise using
macros to print out where functions are called from (and with what sizes)
might help.

> > You init seems quite large at 
> > 91K,  perhaps
> > you should try a smaller one like simple-init.c from userland or the
> > uClinux distro's,
> It's busybox, so i got a shell in there too. But i actually think that
> uClibc is taking most of the space in there. The actual size of the shell
> itself in busybox is about 10k.

Well,  init + shell is probably pulling in a fair amount of uClibc,  and
even if you get a smaller init,  you won't be able to do anything later :-)


David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

More information about the uClinux-dev mailing list