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

[Anton Blanchard]

> 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.

Anton

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