[0/4] RFC: SLB rewrite

[David Gibson]

On Wed, Jul 07, 2004 at 11:31:12AM -0500, Olof Johansson wrote:
>
> David Gibson wrote:
>
> >If there are no serious problems, I'm thinking of pushing at least the
> >first three of these to Linus/akpm in the next week or so.
>
> Good work!  The code looks clean and solid to me.
>
> Maybe the description from the top of the VSID patch should be included
> as a top-of-file comment in slb_low.S or slb.c so it's around for new
> readers in the future?

Not a bad idea.

> Also, where does the nonlinear behaviour at the high segment count
> reload times for the staggered measurements for the new VSID generation
> come from? HTAB hash bucket collissions/clustering?

That I'm not sure.  I don't think it could be from hash
collisions/clustering.  I tweaked my hash bucket simulator
(hashscatter.py, it's in the directory with the images and other
stuff) to simulate the slbmisser program running along with a bunch of
sample programs (essentially 1024 copies of bash).  It shows much
better hash scattering with the new algorithm - maximum bucket
occupancy 6, versus 127 with the old (I'm only computing the primary
hash bucket).

If I take the other processes out, and just simulate slbmisser itself
(plus the linear mapping), it still doesn't show anything untoward -
maxmimum occupancy 2 with the new algorithm, 16 with the old.

So I don't know what's causing the extra cost there.  Possibly just
that the actual VSID scramble itself takes different numbers of cycles
depending on the input?

I do worry a bit about that kink in the graph - what if it continues
to get worse with even larger set sizes, or with the kernel protoVSIDs
(which are numerically larger than user ones)..

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