> >> IE, in theory you could have half your memory free, but
> >> not be able to allocate a single 8k block. Nothing would cause
> >> cache, or InactiveDirty stuff to be written.
> >
> > Which is obviously not the right way to go. I guess we agree in that.
>
> Well, I agree that this is not desirable. I am not sure whether
> the right course is
> (a) to avoid getting here,
> (b) to do traditional page_launder() stuff, i.e. write stuff out,
> and hope that fixes it
> (c) to actively go defragment (Daniel P's prefered approach)
> (d) some combination of the above.
On many systems, higher-order allocations are a really really
small fraction of the allocations, so ideally we'd have them
take the burden of memory fragmentation and won't punish the
normal allocations.
That pretty much rules out very strong forms of (a), things
like (b) and (c) are very possible to do and maybe even easy.
They also won't cause any overhead for normal allocations
since we'd only call them when needed.
regards,
Rik
-- IA64: a worthy successor to i860.http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardvark@nl.linux.org (spam digging piggy)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/