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

["Nathan J. Williams" <nathanw%wasabisystems.com@localhost>]

Tim Kelly <hockey%dialectronics.com@localhost> writes:

> At 12:09 PM -0400 4/11/05, Nathan J. Williams wrote:
> 
> >I'm quite willing to believe that there's more than one bug. Is that
> >also with -O0? As I said in my first mail, I think that the
> >non-Altivec implementation of pmap_copy_page() and pmap_zero_page()
> >have similar issues with accessing local variables when PSL_DR is
> >off. However, I wasn't able to trigger that bug with pmap_subr.c
> >compiled -O0 and pmap_use_altivec forced to 0; I didn't otherwise turn
> >off Altivec.
> 
> Yes, the pmap bug was with optimizations off and Altivec manually turned
> off. It tracked into the same situation that you explained. The code is
> inlined, but referred to a C variable (pa). My main point in pointing this
> out is that it would appear that the approach you recommended is valid
> perhaps across the board.

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.

> Would a short-term solution be to force the code with MSR_DR off be
> optimized?

I've already rewriten the Altivec code to avoid this. I don't think we
have a mechanism in the build system to force optimization to be on
anyway. Until the non-Altivec code is fixed up, I think we can live
with "don't do that".

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

        - Nathan