Date: Sun, 5 Aug 2001 12:29:42 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: John Polstra <jdp@polstra.com> Cc: hackers@freebsd.org Subject: Re: Page Coloring Message-ID: <200108051929.f75JTgF82008@earth.backplane.com> References: <200108030347.f733lIC01436@mass.dis.org> <200108051750.f75Hoce34726@vashon.polstra.com> <200108051913.f75JDir81853@earth.backplane.com> <200108051917.f75JHqn34961@vashon.polstra.com>
index | next in thread | previous in thread | raw e-mail
:> 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.
:
:Yes, I understand that. I'm just trying to find out why Mike keeps
:saying we cannot determine the processor cache characteristics at
:runtime.
:
:John
:--
: John Polstra jdp@polstra.com
You can find out from the cpuid or something like that, but it's
probably easier to simply do it programmatically, or not bother at
all. It's not worth the effort. We would not reap any additional
benefit from knowing.
It is interesting to note that one effect of the page-coloring
code is that the VM CACHE and FREE VM page queues are actually
multi-queues, which means that when I extend the SMP locking down into
them we will wind up with fine-grained locking for memory allocations.
But before I can even begin contemplating that I have to change the way
the vm_page BUSY'ing stuff works so page operations (such as allocations)
can occur without having to hold long term mutexes.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108051929.f75JTgF82008>