Re: 2.6.0 Huge pages not working as expected

[David S. Miller]

On Fri, 26 Dec 2003 20:01:57 -0800 (PST)
Linus Torvalds <torvalds@xxxxxxxx> wrote:

> I can understand a one-way L1, simply to keep the cycle time low, but 
> what's the point of a one-way L2? Braindead external cache controller?

Most sparc64's are the same, as are the ancient sparc32 chips.

Most R4000/R5000 mips chips are like this as well.

It's stupid, but unfortunately pervasive. :)

> Does it keep fragmentation down?
> 
> That's the problem that Davem had in one of his cache-coloring patches: it
> worked well enough if you had lots of memory, but it _totally_ broke down
> when memory was low. You couldn't allocate higher-order pages at all after
> a while because of the fragmented memory.

That's right, but it could also have been because my approach to
the implementation sucked.

For example, if you just keep breaking apart order 1 or greater chunks
to give particular colors out, and later some of them get freed and some
of them don't, you get less and less buddy coalescing over time.

One idea to combat this is to make page liberation (ie. vmscan and friends)
smarter about this when swapping, kicking out page cache pages, or whatever.
Ie. see which freed pages have buddies we can liberate.  I never experimented
with any ideas like that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/