Re: mm fragmentation patch
Trever Adams (highlander@teleteam.net)
Fri, 17 Jul 1998 19:01:31 -0500
> From: MOLNAR Ingo <mingo@valerie.inf.elte.hu>
> On Thu, 16 Jul 1998, Colin Plumb wrote:
>
> > When you use blocks in LIFO (stack) order, the back of the list gets
> > clogged up with blocks that don't get used and don't get combined,
> > either. Because no neighbours want to combine with them, allocating
> > them doesn't block any defragmentation, so they're the best blocks to
> > put to use. But instead a few blocks at the head of the list get all
> > the traffic.
>
> while FIFO is usually better for caching, it has a hidden effect on SMP,
> freshly freed and reallocated dirty pages might generate cross-CPU cache
> invalidation traffic if a page shows up on 'another' CPU. If they are
> LIFO, dirty cachelines get clean in a 'natural' way, by getting kicked out
> of the LRU scheme sometime. (possibly giving a more effective way of
> writeback, instead of the forced writeback)
>
> so LIFO might even end up performing better on SMP, when compared to the
> current allocator.
>
> (although there is a better way to solve this on SMP, by doing per-CPU
> freelists, but anyway)
>
> - -- mingo
>
Is it possible then, since FIFO seems to be best for UP and LIFO to be
best for SMP, to set up the code simply and cleanly to do FIFO for UP
and LIFO for SMP, depending on compile time options?
I imagine even if it is only changing about 7 lines of code that this
could clutter the code a great deal. It may not be the right thing to
do, but it also may be exactly the thing to do.
Trever
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html