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

[Anton Blanchard]

> He did do some timings, the difference was certainly tiny, although it
> might have been (just) measurable.

Yeah it was tiny, although David's slbtest showed it to be on average
just under 1 cycle faster (probably due to averaging the extra
misprediction per 60 iterations).

> Of course, I do also have a plan to get rid of the slbmfee and that
> loop by locking the kernel stack into a fixed SLB slot.  I have a
> patch to do it even, but I need to figure out how to get it to work on
> iSeries.

There are a few more things that would be interesting to look at:

- Are there any more segments we should bolt in? So far we have
  PAGE_OFFSET, VMALLOC_BASE and the kernel stack. It may make sense to
  bolt in a userspace entry or two. The userspace stack is the best
  candidate.  Obviously the more segments we bolt in, the less that are
  available for general use and bolting in more userspace segments will
  mean mostly kernel bound workloads will suffer (eg SFS). It may make
  sense to bolt in an IO region too.

- We currently preload a few userspace segments (stack, pc and task
  unmapped base). Does it make sense to restore the entire SLB state on
  context switch? One problem we have is that we usually enter the
  kernel via libc which is in a different segment to our program text.
  This means we always take an SLB miss when we return out of libc after
  a context switch. (ie we are guaranteed to take one SLB miss per
  context switch)

It would be interesting to get a log of SLB misses for a few workloads.

Anton

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/