Date: Sat, 14 Aug 1999 16:19:56 +1000 From: Bruce Evans <bde@zeta.org.au> To: alc@cs.rice.edu, simokawa@sat.t.u-tokyo.ac.jp Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, rgrimes@gndrsh.aac.dev.com Subject: Re: cvs commit: src/sys/vm vm_page.h Message-ID: <199908140619.QAA14226@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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. Coloring works better immediately after booting. The main problem is that active systems tend to have only a few hundred free pages, so 256 colors would give a small average PQ_FREE length (perhaps < 1). >> 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? Yes. I count PQ_FREE and PQ_CACHE separately. My version of vm_page_alloc() looks in PQ_CACHE if PQ_FREE is empty for the required color but PQ_CACHE isn't, so I'm under-counting PQ_FREE misses relative to -current. Optimisations like this don't actually make much difference, because shortages of a given color are suprisingly long lived. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908140619.QAA14226>