[PATCH 00/10 v6] Fix 8xx MMU/TLB

[Joakim Tjernlund]

Rex Feany <RFeany at mrv.com> wrote on 20/11/2009 21:28:38:
>
> Thus spake Joakim Tjernlund (Joakim.Tjernlund at transmode.se):
>
> > Yet again an iteration of the series.
> > Rex & Scott, please test and signoff.
> > Changes since last version:
> >  - Fix rlwimi insn(from Scott)
>
> Hi Joakim,
>
> Things look much better with this patch set, I see none
> of the random crashes that I had with the earlier patches.
> I'll leave it running on a few boards here over the weekend and
> see if anything bad happens.

Good to hear that.

>
> Since patch #1 fixes a regression in the current kernel
> is there any way you can get that into .32? I know it is late,
> but without that patch .32 doesn't work for 8xx boards.

You need to convince Ben of that. I guess the best you can do
is to reply(include Ben too) with your s-o-b and explain that this
fixes a regression for you.

>
> On another note, how does your patch set affect performance?
> Have you been able to do any testing?  What is the advantage
> of using dcbX in the kernel, besides keeping the code
> similar to other ppc platforms?

I consider this a big plus, not having to pay special attention
to 8xx anymore. There aren't many 8xx people around
to fix problems that are specific for 8xx.

> Maybe it is good to
> catch/fixup userspace uses of dcbX, but why change the
> kernel? How does it affect performance?

when I originally did the dcbX path many years ago I did
some perf testing and it was a win. Perhaps you could
run a some tests?

Consider that the dcbx workaround is only triggered by a DTLB errors
and the kernel never gets into DTLB errors for normal activity.

TLB errors are the slow path anyway with lots of mm code
so a few more insn won't matter.

There is also the case of dcbst setting the store bit wrongly
and this could generate a SEGV if it hits a RO page.

The kernel isn't free of dcbX insn anyway so if it ever hit
a DTLB error, it is possible that could bring down the kernel.

The only perf regression I can think of is the
  8xx: Remove DIRTY pte handling in DTLB Error.
which will make dirty handling much slower.
I am happy to leave that one out, but Ben requested
this.

 Jocke

PS.
    You should consider fixing glibc's mem* functions to make
    use of dcbX for 8xx once the kernel has this patchset.