From owner-freebsd-current Sun Feb 7 01:01:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA26114 for freebsd-current-outgoing; Sun, 7 Feb 1999 01:01:28 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA26102 for ; Sun, 7 Feb 1999 01:01:27 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 3703 invoked from network); 7 Feb 1999 09:01:22 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 7 Feb 1999 09:01:22 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id EAA26213; Sun, 7 Feb 1999 04:01:21 -0500 (EST) Message-Id: <199902070901.EAA26213@y.dyson.net> Subject: Re: Significant page coloring improvement In-Reply-To: <199902070839.AAA20087@apollo.backplane.com> from Matthew Dillon at "Feb 7, 99 00:39:28 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sun, 7 Feb 1999 04:01:21 -0500 (EST) Cc: dyson@iquest.net, current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > > Ah, interesting. I understand the second bit. The first bit seems > somewhat odd, though - the automatic page coloring adjustment made > by _vm_object_allocate() doesn't work well enough for kmem_object? > The problem with it was that there appeared to be a clash. The color allocation in _vm_object_allocate is ad-hoc, and tuned for a general case, essentially randomizing the coloring (but also statistically coloring processes approximately correctly.) My original code (and I forget if the current code does this) attempts to color the objects (or pages in the objects) so that there isn't much overlap in normal processes. There is still an opportunity to improve the color allocations. I also have some mods that remove the L1 coloring (since it is overkill, and just complicates the code.) L2 coloring (or L3 as appropriate on machines like Alphas) is all that is needed!!! I did the L1 coloring for an exercise, and forgot reality when I committed the code :-). (Okay, that isn't quite true, I did think that L1 coloring would have been useful -- but after alot of thought and paper research, have decided that L1 page coloring for a small L1 cache is kind-of useless.) If you want to see the L1 mods and perhaps remove the L1 coloring, you are welcome and it would be a good thing to remove it. The L1 mods are pretty much straight-forward, and might be a compromise between removing the coloring all together and keeping all of the complexity. I do suggest that the base color allocation (and proper management of the coloring) would be a good day or so project to clean-up. Again, right now, the coloring looks okay, and the kernel page coloring choices were just a degenerate case. The low level coloring code is good -- so improving the upper level mgmt is fertile ground. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message