: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. : :dy...@iquest.net | it makes one look stupid -Matt Matthew Dillon <dil...@backplane.com> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message