[uClinux-dev] in.h and Ethernet
davidm at snapgear.com
Fri Nov 23 00:39:05 EST 2001
Jivin Tom Walsh lays it down ...
> "Kendrick G. Hamilton" wrote:
> > On Thu, 22 Nov 2001, Bruce Paterson wrote:
> > > "Kendrick G. Hamilton" wrote:
> > > >
> > > > Bruce,
> > > > we are using busybox for ifconfig under linux 2.0.38
> > >
> > > Thanks for that. Yes that would appear to compile fine. I had a bit of a
> > > mismash of stuff between
> > > busybox and others and I have rationalised my app list a bit (it's only
> > > when you get
> > > to the busybox part of the new makefile system you realise you should
> > > have said No to a lot
> > > of the earlier questions). Actually its easier editing the config file
> > > by hand.
> > >
> > > You mentioned in another list email about some small mods needed to the
> > > ethernet driver to get it
> > > working with 2.4.x (as distinct from 2.0.38). What were they ?
> > > I have the mleslie 2.0.38 version working fine, but I'm hoping the 68k
> > > memory leak problems with
> > > 2.4.x may be found soon (who knows I might even find one).
> > We would run free then another program then free again. Free was reporting
> > less and less free memory. Our system only has 2Meg of RAM so we would
> > eventually run out of RAM.
> > As for getting 68EN360 ethernet support working under 2.4.x kernel, see
> > Rubini and Corbet, Linux Device Drivers, 2nd Edition. The CVS release of
> > the 2.4.x kernel included the 2.0.38 code(I think) but did not try
> > compiling or linking it with the kernel.
> I am not aware of any memory leaks in the 2.4 kernel, you can get a
Likewise, I don't know of any leaks. 2.4 can be a little confusing with
the way is cleans out dirty cache/buffer pages. It looks like there is
less memeory than there is. When yu run low the kswapd process goes around
finding more memory for you.
> problem of fracturing the memory by alloc/free too many times. There is
> a tendancy for the memory to become broken into smaller fragments and it
> not being viewed by the o/s as being contigous. I believe that this
> tends to happen normally (if you really insist on many alloc/free cycles
> in your application code. This may also tend to happen if you have a
> daemon and a lot of forking is occuring, then when you attempt to do
> something like alloc a 400K block, it may fail.
Fragmentation is a killer, worse still, with a power of 2 allocator you
will actually need 512K of free contiguous memory on a 512K byte boundary
to alloc 400K. Not an easy thing to achieve with even small levels of
> There is more indepth information in the archives about this:
> http://uClinux.home.at, check there.. This is one of the drawbacks of
> not having an MMU, the uClibc library does have two memory allocators:
> simple and complex. The uClibc is normally running in the simple
> malloc/free mode (default), This tends to fragment more, but is faster
> than the more complex allocator.
> DavidM, correct me if I am wrong here..
Sounds good to me, here's the deal with malloc implementations:
* application does only a few allocations (big/small) use malloc-simple
* application does lots (ie., 1000's) or small allocations
then use 'libsmalloc' or some other malloc.
Normally you identify painful apps and either fix them or just link them
against the larger malloc and let everyone else use malloc-simple.
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