[1/4] RFC: SLB rewrite (core rewrite)

[David Gibson]

On Tue, Jul 13, 2004 at 10:43:16AM +1000, Anton Blanchard wrote:
>
>
> > Indeed.  My gut instinct would be that we want to keep the number of
> > bolted segments down, so as much of the SLB can be used as flexibly as
> > possible.
>
> Agreed.
>
> > That said, I've had a couple of ideas on how to generate some
> > semblence of LRU data in ways that might be sufficiently low overhead
> > to be practical.  For example, what if we kept a variable containing
> > the ESID of the last segment cast out from the SLB.  Whenever we take
> > an SLB miss, we check the EA against that stored segment.  If they
> > match - i.e. this segment is so heavily used that we want it again
> > almost as soon as we've thrown it out - we put a flag indicating to
> > skip over this slot for some number of future misses.
>
> Interesting idea. The segments that I have seen miss a lot are:
>
> userspace
> 	stack
> 	PC
> 	libc segment
>
> kernel
> 	task struct
>
> The match EA against last castout should be able to catch these and has
> the advantage of adapting to various workloads.
>
> > It certainly would.  We really want to run some simulations to see how
> > bolting various segments, or schemes like those above would affect the
> > SLB miss rate.
>
> If we cut the amount of the SLB we use to a minimum we could get a
> rather accurate log of SLB accesses. Does the SLB miss handler touch
> anything outside segment 0 in your rewrite? If it doesnt we could use
> only one slot for replacement, and then log every miss we take.

Yes, that should work, the new handler shouldn't touch anything
outside segment 0.

--
David Gibson			| For every complex problem there is a
david AT gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.