Re: cvs commit: src/sys/vm vm_page.h

[ Available lists | Index of cvs-all | Month of Aug 1999 | Week of 13 Aug 1999 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
Date
13 Aug 1999 14:50:08
Subject
Re: cvs commit: src/sys/vm vm_page.h
Message-ID
14260.37648.315208.25254T@ett.sat.t.u-tokyo.ac.jp

In reply to

[ Hide this part ]
At Fri, 13 Aug 1999 15:33:31 -0500,
Alan Cox <alc@cs.rice.edu> wrote:
>
> On Sat, Aug 14, 1999 at 04:57:45AM +0900, Hidetoshi Shimokawa wrote:
> > ...
> >
> > As for 21164 Alpha, it has 96KB 3-way L2 cache.
> > So it needs only 4 (= 96KB / 8KB / 3) colors.
> >
> > My Alpha box has 4MB direct-map L3 cache and
> > it needs 4MB / 8KB = 512 colors. I have the following entries in my
> > vm_page.h
> >
>
> I am afraid that the current implementation of page coloring doesn't
> scale very well to such a large number of colors, especially if you
> don't have an extremely large amount of physical memory. Far too often,

It could be. Last time I checked, 256 colors gives best user-time
while kernel-build benchmark.
My machine is with 512MB physical memory.

> it's unable to allocate a page of the appropriate color. Even with
> just 8 colors on a machine with 320MB of physical memory, the number
> of times that coloring fails during a "make world" is extraordinary.

How do you detect 'coloring failure'?
By adding counter in vm_page_list_find?

> Bruce Evans and I are looking into this...if someone with an Alpha
> has time to help out that could be useful.

At least, alpha lacks pre-zeroed pages because vm_page_zero_idle is
not enabled...

--
/\ Hidetoshi Shimokawa
\/ simokawa@sat.t.u-tokyo.ac.jp
PGP public key: finger -l simokawa@sat.t.u-tokyo.ac.jp


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message



Elapsed time: 2.060 seconds