Rex Feany <rfe...@mrv.com> wrote on 20/11/2009 21:28:38:
>
> Thus spake Joakim Tjernlund (joakim.tjernl...@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.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
