Date: Sun, 5 Aug 2001 12:13:44 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: John Polstra <jdp@polstra.com> Cc: hackers@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: Page Coloring Message-ID: <200108051913.f75JDir81853@earth.backplane.com> References: <200108030347.f733lIC01436@mass.dis.org> <200108051750.f75Hoce34726@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:In article <200108030347.f733lIC01436@mass.dis.org>,
:Mike Smith <msmith@FreeBSD.ORG> wrote:
:>
:> It looks about right, but page colouring is pointless unless and until we
:> can determine the processor cache characteristics at runtime.
:>
:> Which we can't.
:
:Why can't we do this at least on the i386 with the CPUID instruction,
:initial %eax == 2? It returns cache size, associativity, and line
:size for both the L1 and L2 caches. As far as I can tell, it works
:for the Pentium Pro and subsequent processors.
:
:John
:--
: John Polstra jdp@polstra.com
Well, first of all the page coloring is not pointless with the
sizes hardwired. The cache characteristics do not have to
match exactly for page coloring to work. The effectiveness is
like a log-graph, and you don't lose a lot by guessing wrong.
Once you get past a designated cache size of 4-pages or so you've
already reaped 90% of the benefit on systems which use N-way (2, 4, 8)
associative caches (which is most systems these days). For systems with
direct-mapped caches you reap 90% of the benefits once you get past
16 pages or so.
Since most L1 caches these days are at least 16K and most L2 caches
these days are at least 64K (and often much higher, such as on the IA32),
our hardwired page coloring constants wind up being about 95% effective
across the entire range of chips our OS currently runs on.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108051913.f75JDir81853>