Matthew Dillon said: > > : next_index += PQ_L2_SIZE/4; > : if (next_index > PQ_L2_MASK) > : next_index = (next_index + 1) & PQ_L2_MASK; > > Oops, make that: > > next_index += PQ_L2_SIZE/4; > if (next_index > PQ_L2_MASK) > next_index = (next_index + PQ_PRIME1) & PQ_L2_MASK; > > Or even just: > > next_index = (next_index + PQ_PRIME1) & PQ_L2_MASK; > > Both seem to work pretty well w/ lmbench, though nothing really sticks > its nose out. > The reason why you might want to incr by PQ_L2_SIZE/N (or some other large number) is that it will likely decrease conflicts for larger objects.
Note that the color should be chosen with more context (virtual address or memory region type like shared lib) than I originally implemented. There are better approaches that take into consideration dynamic conflicts. Such dynamic conflicts might be more complex to determine, and a good static choice adds only minimal overhead, yet provides some improvement. I suggest that until a major project can be undertaken, the static stuff is the right thing. It is easy to screw things up (as you can tell by my original choice for coloring being suboptimal, but not necessarily destructive.) I am agnostic regarding the coloring scheme, but I am glad that removing L1 coloring might be acceptable... If anything, it will decrease instruction cache footprint, and not cause a significant (hopefully any) decrease in performance. I will try to package up the patches (it is an issue of merging them in from my codebase.) They are essentially a result of hand optimizing the case of setting PQ_L1_SIZE to 1. Give me a day or so to put it together. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message