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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
