RFC: Use bitmaps to track free/user SLB slots
David Gibson
david at gibson.dropbear.id.au
Fri Dec 23 09:45:36 EST 2005
On Thu, Dec 22, 2005 at 09:31:57AM -0600, Olof Johansson wrote:
> 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?
Yes. Well, except I don't think it's really more complex than the
various cases of dealing with not-full-cache, just-full-cache and
overfull-cache we have now.
> 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.
We already know we get a heap of SLB misses with some workloads
(database, mostly, IIRC). Whether this will help significantly I
don't know, but since it's one of an extremely few things I can think
of which might conceivably reduce the SLB miss rate, I think it's
worth testing.
Bear in mind that a single SLB miss is around 200 cycles.
> 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
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
More information about the Linuxppc64-dev
mailing list