On Wed, Jan 29, 2003 at 10:00:11AM -0800, William Lee Irwin III wrote:
> >> reg00: base=0xc0000000 (49152MB), size=16384MB: uncachable, count=1
> >> reg01: base=0x00000000 ( 0MB), size=524288MB: write-back, count=1
> >> reg02: base=0x800000000 (524288MB), size=262144MB: write-back, count=1
> >> Yes, this is standard ia32 (P-III/Coppermine cpus), and hence the
> >> numbers here are utter garbage.
>
> On Wed, Jan 29, 2003 at 05:48:42PM +0000, Dave Jones wrote:
> > Bizarre. The size field isn't being shifted, and your base is somewhere
> > off in 64bit land.
> > See Andi's "RED-PEN" comments in various parts of arch/i386/kernel/cpu/mtrr/
> > They need fixing at some point, and could be the cause of your problems.
>
> OTOH since 0-512GB are in there this explains why the (massive) perf.
> decrease only happens sometimes. The MTRR corruption issues are only
> visible with 48GB atm. I haven't been focusing on MTRR's but I may
> arrange to trace the codepaths etc. in the eventual future to find
> where the bits are going bad esp. as benchmark time approaches.
ohhh, 48GB. I forgot you were doing the silly-amounts-of-mem thing.
Its extremely likely you'll have to fix up those comments Andi made,
and possibly some other parts too. That code should be 64bit clean
now (due to x86-64 sharing it), but there may still be some gotchas,
especially on weird-ass systems like what you've been playing with 8)
Dave
-- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 31 2003 - 22:00:22 EST