Page Coloring Defines in vm_page.h

[David Schultz]

On Tue, Jun 24, 2003, Bruce M Simpson wrote:
> Hi all,
> 
> Something occurred to me whilst I was re-reading the 'Design Elements'
> article over the weekend; our page coloring algorithm, as it stands,
> might not be optimal for non-Intel CPUs.
> 
> Spiel:
>   - Dillon's VM article talks about L1 cache reference, rather than L2. 
>     This is a fair assumption to make as previously L2 caches were not
>     located on the die. With most i386 processors these days the cache
>     is located on the die and runs at full CPU clock speed, as well as
>     having a dedicated cache access bus on the die. Notably Katmai's
>     runs at half the processor speed; Coppermine and later run the cache
>     at full processor speed.

The coloring is based on the size and associativity of the cache,
not its speed relative to the processor's.

>    - Why is this important? The vm code as it stands assumes that we
>      colour for L2 cache. This might not be optimal for all architectures,
>      or, indeed, forthcoming x86 chips.

The code makes no assumptions about whether the cache is primary
or secondary, except that the variables are named that way, and
the default is optimized for a 4-way 512K cache.  (You could
determine the actual L2 cache size at boot time via the CPUID
instruction on PII and later Intel chips if you wanted to.)  You
really want to color for the L2 cache, though; the L1 instruction
and data caches are usually small and hard to color for, and
occasional false sharing there doesn't cost much if you have an
L2.  There used to be L1 coloring support, but it was removed some
time ago.

>   - If someone could fill me in on how the primes are arrived at that
>     would be very helpful.

Good question.  I know why they're prime numbers slightly smaller
than a power of two, but I can't figure out how that power of two
was chosen.