RFC: Use bitmaps to track free/user SLB slots
Olof Johansson
olof at lixom.net
Fri Dec 23 02:31:57 EST 2005
On Thu, Dec 22, 2005 at 05:42:35PM +1100, David Gibson wrote:
> This needs way more testing and thought before being considered for
> merging, but here it is in case people are interested. It implements
> a new, possibly superior approach to managing SLB entries.
[...]
> My preliminary tests (on POWER5 LPAR) seem to indicate that this has
> essentially no effect (delta<1ns) on the time for a user SLB miss (the
> cost of the bitmap manipulation is the same as that for maintaining
> the old slb cache). Time for kernel SLB misses is probably slightly
> increased; not measured, but I think it should be delta<~5ns. Context
> switch time may be increased slightlyl; also not measured yet, but I
> think it should be <0.5us at most and quite likely negligible in
> comparison to the rest of a context switch. I've no idea what the
> impact on SLB miss rates for various workloads might be.
So, essentially what you're saying is that it's more complex than the
older one, slightly slower in the execution path and it has no proven
benefit?
Until we see numbers where the old code causes too much SLB misses, and
this patch reduces the miss rate, this is just unneeded complexity and
over-engineering. But I'd be happy to be proven wrong on this.
I'll have a read-through of the code as well, but I need some coffee
before that, especially given the lack of comments in the new assembly.
:-)
-Olof
More information about the Linuxppc64-dev
mailing list