Page Coloring Defines in vm_page.h

[Bruce M Simpson]

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.

   - 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.

  - PQ_L2_SIZE seems to refer to total L2 cache size / N sets.

  - The defines in vm_page.h seem to assume a 4-way set associative
    cache organization. 

  - The page queue structures are sized according to these
    defines at boot-time.

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

Comments/discussion/correction welcomed, it would be good to get some
feedback on this before I start patching my tree.

BMS