Re: Followup: MCHK exception in -current with MMU off

[Tim Kelly <hockey%dialectronics.com@localhost>]

At 2:28 PM -0400 4/11/05, Nathan J. Williams wrote:
>Hmm. I removed "options ALTIVEC" from my kernel configuration,
>reconfigured, and rebuilt, and I wasn't able to get a MCHK on my
>G4. Since this problem depends a great deal on getting lucky or
>unlucky with the compiler's choice of optimization, the exact source
>and configuration probably make a difference.

And I've made a mistake in my remembering.  The code in pmap_syncicache
that I believe to have been causing the MCHK with non-Altivec was not
inlined assembly.  It does contain pa and is within a section that has
MSR_DR off, but is not inlined.

>> Additionally, is the Altivec specific code fast enough to
>> warrant using it even though it causes overhead on non-Altivec CPUs like
>> G3s to make sure Altivec can be used? If Altivec was not enabled by
>> default, but an option, it could constrain the code to within #defines
>> while eliminating the conditional across the board.
>
>Er, it is an option, and it is protected by #defines. The code in
>pmap_subr.c looks like:
>
>#ifdef ALTIVEC
>        if (pmap_use_altivec) {
>                vcopypage(dst, src);
>                return;
>        }
>#endif
>
>so there's a slight overhead for a GENERIC kernel on a non-Altivec
>machine, but not with a custom kernel. You're suggesting turning off
>Altivec by default, so that GENERIC is slightly faster on a G3 but
>slower on a G4? I don't think that's the right tradeoff; the cost of
>the test and branch is pretty low compared to the cost of the entire
>copy/zero page operation.

For clarity, I was suggesting something like

#ifdef ALTIVEC
                vcopypage(dst, src);
                return;
#endif

and turning off Altivec for GENERIC.  Not that GENERIC isn't stable with
Altivec, but on a memory access instead of a floating point calculation, I
didn't think that this optimization would be that important.  I wasn't
aware that Altivec will access memory faster than the GPRs.  If someone
wanted to build a kernel with the Altivec option, that's something they
could take on, but the stock kernel wouldn't use it unless it was FPU
stuff.  It'd reduce the size of the GENERIC kernel and eliminate the
conditional for everyone, including G4.  The current approach gives
preferential treatment for G4 CPUs and makes everyone else compile without
the Altivec option if they don't need it.  It's mainly a matter of making
GENERIC be as generic as possible, but it was just a suggestion.

tim