Jivin Jamie Lokier lays it down ...
> David Spain wrote:
> > I forgot to add the obligatory:
> >
> > uclinux-2.4.32-uc0 from the 20060803 drop.
> > Compiled with the gcc 2.95.3 binutils.
>
> page_alloc2.c is better for reducing fragmentation and also being less
> sensitive to it, but it doesn't interact with kswapd's wakeup logic in
> quite the way it's supposed to, as far as I can tell. It seems to
> make it work more often than necessary.
>
> page_alloc.c is better for fast allocations, and for keeping more
> memory free when there is a steady stream of allocations (e.g. when
> streaming data from disk), but after many allocation-free cycles of
> large blocks (e.g. when running executables), the system becomes very
> fragmented.
>
> (I was bitten by this in a different way: I'm using vendor-supplied
> uclinux kernels, and they are configured to use page_alloc2.c. The
> added CPU usage caused the vendor to tweak things to reduce it, and
> when streaming files from disk those tweaks caused kswapd to fail to
> respond quickly enough, causing out of memory failures... But the
> unpatched uclinux code used too much CPU. We found a compromise).
Feel free to send in some patches :-)
Are you low on memory ? page_alloc2 gets pretty nasty about trying to
clear the caches etc as often as possible to keep as much contiguous
memory available at all times.
That said, I have seen systems where kswapd CPU usage is not a problem,
and oviously there are those where it is. I don't know the cause. 2
possibilities:
1) I haven't actively used a 2.4 kernel on a non-MMU system for some
time and the page_alloc2 code may just be wrong due to a kernel
update and bit rot.
2) The usage on these systems is triggering the behaviour.
If you boot te hsystem is a configuration that doesn't use much RAM and
don't start and nasty big apps is the system idle (ie kswapd is
behaving). If so what triggers it's rampage ?
Cheers,
Davidm
--
David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
