Date: Sun, 7 Feb 1999 01:26:25 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "John S. Dyson" <dyson@iquest.net> Cc: current@FreeBSD.ORG Subject: Re: Significant page coloring improvement Message-ID: <199902070926.BAA20420@apollo.backplane.com> References: <199902070901.EAA26213@y.dyson.net>
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.
The standard increment in _vm_object_allocate() is:
if ( size > (PQ_L2_SIZE / 3 + PQ_PRIME1))
incr = PQ_L2_SIZE / 3 + PQ_PRIME1;
else
incr = size;
next_index = (next_index + incr) & PQ_L2_MASK;
Which, for the kmem_object you are overriding with:
kmem_object->pg_color = (kernel_object->pg_color + PQ_L2_SIZE/4) &
PQ_L2_MASK;
Would it make more sense to change vm_object_allocate() to simply
increment by PQ_L2_SIZE/4 plus an additional 1 if it rolls over and
then not do anything special for kmem_object? Like this:
next_index += PQ_L2_SIZE/4;
if (next_index > PQ_L2_MASK)
next_index = (next_index + 1) & PQ_L2_MASK;
I don't see much point in trying to include the object size in the
pg_color optimization since an objects tends to be acted upon in a
non-contiguous manner relative to other objects. In fact, dividing
PQ_L2_SIZE by 3 and adding 5 ( for PQ_NORMALCACHE case ) doesn't even
give us a pseudo-random distribution since that increment is '10', which
is an even number.
: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.
If the L1 coloring doesn't help, I'd love to remove it. It wouldn't be
a big deal, though, since presumably the only two routines we are talking
about are vm_page_select_free() and vm_page_list_find(). Still, there
are a bunch of #if 0's ( surrounding the now defunct object->page_hint
stuff ) in vm_page.c that I could clean up at the same time, so lay
those diffs on me!
: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.
:
:dyson@iquest.net | it makes one look stupid
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199902070926.BAA20420>