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