Re: mm fragmentation patch

David S. Miller (davem@dm.cobaltmicro.com)
Fri, 17 Jul 1998 06:17:08 -0700


Date: Fri, 17 Jul 1998 05:54:01 -0600 (MDT)
From: Colin Plumb <colin@nyx.net>

Could you combine the two? I'm thinking about having a "last CPU"
index in each block header, and a CPU first searches for an available
block that was last used by it (in FIFO order), and only steals from
another CPU if it has trouble.

While there are still SMP inefficiencies, this lets global combining
take place while preserving the essential processor affinity.

Just a dumb idea...

One thing to keep in mind when you start to consider per-cpu
allocation pool schemes.

Stay away from "try from mine, else steal from others" schemes,
because it implies a lock being needed just to allocate from your
local pool. To make it worthwhile we'd like it to cost nothing,
ie. no locking, for the "grab from local CPU pool" cases. Once you
directly allow stealing from non-self CPU pools you run into complex
and inefficient mechanisms.

The approach I like (as evidenced by how the pgtable cache works on
SMP) is to keep the pools very small, so stealing is never a real
issue.

So in this case, when you locally notice memory is low, you locally
steal from your pool. And because your pools are always kept small,
you never can contribute significantly to system wide memory
shortage.

Just a dumb observation... :-)

Later,
David S. Miller
davem@dm.cobaltmicro.com

-
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