Date: Mon, 6 Aug 2001 01:31:18 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Sergey Babkin <babkin@bellatlantic.net> Cc: John Polstra <jdp@polstra.com>, hackers@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: Page Coloring Message-ID: <200108060831.f768VI985471@earth.backplane.com> References: <200108030347.f733lIC01436@mass.dis.org> <200108051750.f75Hoce34726@vashon.polstra.com> <200108051913.f75JDir81853@earth.backplane.com> <3B6DE9F4.FC8D46F8@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:If I remember correctly from reading a thesis (can't remember its
:author) on the page coloring which I believe widely introduced this
:concept, page coloring adds a lot of efficiency to the directly
:mapped caches but even for the 2-way caches is nearly pointless.
:
:-SB
For the most part, yes. 2-way set associative caches handle standard
compiled programs reasonably well. 4-way set associative
caches handle standard interpreted programs reasonably well.
Page-coloring helps keep things consistent between program runs
but typically has very little effect on machines which already have
set-associative caches. The main thing is the consistency - for
example, if you have a medium-sized buffer in memory which you are
accessing randomly, page coloring will prevent degenerate cache cases that
can occur in cases where the VM system (without coloring) happens to
assign the same cache page to every page of the buffer. But you wouldn't
notice unless your buffer had more then N pages (N = set associativity).
For the same reason, 'random' also works fairly well (just in a less
consistent way), which is why page coloring doesn't add much when doing
a performance comparison on a system with a 2-way or better associative
cache.
-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?200108060831.f768VI985471>