[uClinux-dev] How to know what's taking place in memory
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
Depending on how this is accounted for may explain why the numbers don't
> > > 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
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)
> > 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