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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:28 EST