From owner-cvs-all Fri Aug 13 14:50: 8 1999 Delivered-To: cvs-all@freebsd.org Received: from gate.keisu.t.u-tokyo.ac.jp (ns06.t.u-tokyo.ac.jp [133.11.68.1]) by hub.freebsd.org (Postfix) with SMTP id 69B5414FCF for ; Fri, 13 Aug 1999 14:49:54 -0700 (PDT) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: (qmail 89572 invoked from network); 13 Aug 1999 21:50:09 -0000 Received: from sylph.sat.t.u-tokyo.ac.jp (10.6.1.20) by ns06.t.u-tokyo.ac.jp with SMTP; 13 Aug 1999 21:50:09 -0000 Received: from ett.sat.t.u-tokyo.ac.jp (ett.sat.t.u-tokyo.ac.jp [10.6.1.30]) by sylph.sat.t.u-tokyo.ac.jp (Postfix) with ESMTP id 693B62DAA9; Sat, 14 Aug 1999 06:50:09 +0900 (JST) Received: from ett.sat.t.u-tokyo.ac.jp by ett.sat.t.u-tokyo.ac.jp (8.9.3/sat-V0.6) id GAA36644; Sat, 14 Aug 1999 06:50:09 +0900 (JST) Date: Sat, 14 Aug 1999 06:50:08 +0900 Message-ID: <14260.37648.315208.25254T@ett.sat.t.u-tokyo.ac.jp> From: Hidetoshi Shimokawa To: alc@cs.rice.edu Cc: rgrimes@gndrsh.aac.dev.com, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/vm vm_page.h In-Reply-To: In your message of "Fri, 13 Aug 1999 15:33:31 -0500" <19990813153331.C26372@nonpc.cs.rice.edu> References: <199908122116.OAA56955@freefall.freebsd.org> <199908131458.HAA01346@gndrsh.aac.dev.com> <19990813140128.C27982@cs.rice.edu> <14260.30905.562825.38243A@ett.sat.t.u-tokyo.ac.jp> <19990813153331.C26372@nonpc.cs.rice.edu> User-Agent: Wanderlust/1.0.0 (Kokomo) SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) MULE XEmacs/21.2 (beta13) (Demeter) (i386-unknown-freebsd3.1) X-Face: OE([KxWyJI0r[R~S/>7ia}SJ)i%a,$-9%7{*yihQk|]gl}2p#"oXmX/fT}Bn7:#j7i14gu$ jgR\S*&C3R/pJX 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