[uClinux-dev] memory fragmentation

Farrell Aultman fja0568 at gmail.com
Wed Feb 11 10:55:16 EST 2009


We have been fighting this problem for 4 years using uClinux 2.4.  Upgrading
to uClinux 2.6 is not an option for me right now.  It really helps if you
write all of your apps in C and statically allocate all of your memory.  You
can make programs that reload often "execute in place".  Another trick is to
use bget on a per program basis to allocate a chuck of memory for that app,
and let bget manage it.

Farrell

On Wed, Feb 11, 2009 at 3:25 AM, Jamie Lokier <jamie at shareable.org> wrote:

> Andrei Martynov wrote:
> > Tuesday, February 10, 2009, 1:27:53 PM, Jamie Lokier wrote:
> >
> > > The problem you have isn't really that it uses all memory for disk
> > > cache - that's a good thing
> >
> > I believe that any continuos memory (re)allocation is evil on nommu
> > platform with limited resources and should be avoided.
> >
> > How do others solve memory fragmentation problem?
>
> In general it's a hard problem.
>
> On no-MMU, Linux 2.4 mostly solved it with page_alloc2.c at some cost
> to performance.  But even that doesn't work if you have something
> streaming large files from disk - additional tweaks are required, and
> they aren't completely reliable.
>
> There have been some efforts to solve memory fragmentation on big
> servers (with MMU) in Linux 2.6.  Distinguishing short-lived and
> long-lived pages is part of that, so is moveable pages (I don't know
> if that fully works), and something called "lumpy reclaim".
>
> That's why I suggested trying a later kernel than 2.6.24, because some
> anti-fragmentation patches are in .26, .27, .29-rc4 etc.  (Just
> download the ChangeLog files from kernel.org and you'll see
> fragmentation mentioned).
>
> Some anti-fragmentation patches aren't in the mainline kernels yet.
>
> I don't know if the server anti-fragmentation code is effective on a
> smaller no-MMU device.  It's worth trying.
>
> -- Jamie
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20090211/cf87c401/attachment.html>


More information about the uClinux-dev mailing list