Date: Sun, 7 Feb 1999 04:01:21 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: dyson@iquest.net, current@FreeBSD.ORG Subject: Re: Significant page coloring improvement Message-ID: <199902070901.EAA26213@y.dyson.net> In-Reply-To: <199902070839.AAA20087@apollo.backplane.com> from Matthew Dillon at "Feb 7, 99 00:39:28 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902070901.EAA26213>