Re: large page patch (fwd) (fwd)

[Hubertus Franke <frankeh@watson.ibm.com>]

On Monday 05 August 2002 12:59 pm, David Mosberger wrote:
> >>>>> On Sun, 4 Aug 2002 15:30:24 -0400, Hubertus Franke
> >>>>> <frankeh@watson.ibm.com> said:
>
>   Hubertus> Yes, if we (correctly) assume that page coloring only buys
>   Hubertus> you significant benefits for small associative caches
>   Hubertus> (e.g. <4 or <= 8).
>
> This seems to be a popular misconception.  Yes, page-coloring
> obviously plays no role as long as your cache no bigger than
> PAGE_SIZE*ASSOCIATIVITY.  IIRC, Xeon can have up to 1MB of cache and I
> bet that it doesn't have a 1MB/4KB=256-way associative cache.  Thus,
> I'm quite confident that it's possible to observe significant
> page-coloring effects even on a Xeon.
>
> 	--david

The wording was "significant" benefits.
The point is/was that as your associativity goes up, the likelihood of 
full cache occupancy increases, with cache thrashing in each class decreasing.
Would have to dig through the literature to figure out at what point 
the benefits are insignificant (<1 %) wrt page coloring.

I am probably missing something in your argument?
How is the Xeon cache indexed (bits), what's the cache line size ?
My assumptions are as follows. 

Take the bits of an address to be two different bit assignments.

< PG , PGOFS >  with PG=V,X  and PGOFS=<Y,Z>  =>   < <V, X>, Y, Z >
where Z is the cacheline size,   
<X,Y> is used to index the cache (that is not strictly required to be 
contiguous, but apparently many arch do it that way).
Page coloring should guarantee that X remains the same in the virtual and the 
physical address assigned to it.
As your associativity goes up, your number of rows (colors) in the cache comes 
down !!

We can take this offline as to not bother the rest, your call. Just interested 
in flushing out the arguments.

-- 
-- Hubertus Franke  (frankeh@watson.ibm.com)