Messages in this thread |  | | Date | Wed, 29 Jan 2003 18:12:15 +0000 | From | Dave Jones <> | Subject | Re: no more MTRRs available ? |
| |
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/
|  |