Re: [RFC] Cachemap for 2.6.12rc4-mm1. Was Re: [PATCH] enhance x86 MTRR handling

[Andi Kleen <ak@suse.de>]

On Fri, May 13, 2005 at 07:24:22AM -0700, Dave Hansen wrote:
> On Fri, 2005-05-13 at 15:29 +0200, Andi Kleen wrote:
> > > : x86-64 will need updating to also take advantage of this.
> > >   It may be able to just copy the i386 includes as-is, I've
> > >   not looked closely at the PAT related changes on x86-64 yet. Andi?
> > > 
> > > : The list manipulation macros in mm/cachemap.c are a little fugly.
> > > 
> > > Anything else ?
> > 
> > For memory (pfn_valid == 1) it would be more memory efficient to use a few bits
> > in struct page->flags
> 
> I think page->flags use should be limited to things that are relatively
> performance-sensitive and arch-independent, mostly because we're running
> out of them on 32-bit platforms, fast.

That is mostly because we encode the zone number in there, which
never seemed like a particularly useful optimization to me (because
zone is not that expensive to recompute using a small hash table)
If the zone number was removed there would be plenty of bits.

There are 12 bits left  then, which is plenty.

In fact one bit is already reserved for PAT like this (PG_uncached),
PAT would probably only need another one so that write combining
can be expressed too. That could be even done without getting rid of the 
zone number.

> Each incremental use of page flags doesn't have any immediate storage
> cost, but it's a serious pain when we run out, and having to bloat it to
> a 64-bit value on 32-bit platforms wouldn't be very memory efficient,
> either. :)
> 
> > In general because there are lots of uses of "range lists" it would be better
> > to put it as a library into lib.
> 
> Either that, or something like "Dynamically allocated pageflags" would
> be nice.
> 
> 	http://lwn.net/Articles/124332/

Looks quite ugly and overkill.

-Andi