Messages in this thread | | | Date | Thu, 24 Dec 1998 13:02:45 +1100 | From | Richard Gooch <> | Subject | Re: MTRR testbeds?? |
| |
John Michael Clemens writes: > In rummaging through the IDT WinChip Doc's, i discovered that they > support thier own variant of the PPro/PII MTRR's (their "Memory > Configuration Registers"), and can be set to write-combine for > strings, stacks, and non-strings/non-stacks (as well as weak/strong > ordering and some other stuff)...I've started writing some code in > the hopes of merging it eventually with the existing MTRR > code...(i'm running 2.1.132)
I'm sitting on some patches written by Rafael which hacked the MTRR code to work for IBM/Cryix. By the time 2.3 is released I should have some time to integrate these patches (Rafael thought the Intel support may have been broken by his hacks:-). I'm planning a framework for supporting different CPUs in a nice, easy way.
I don't think there is any point at the moment: I doubt Linus would accept things at this late stage anyway. What we have now looks quite robust. I'd also like to see the new XFree86 X server make use of /proc/mtrr for a while and see what lessons are to be learnt from that end.
I expect that once developments in 2.3 for the MTRR code have stabilised and shown to be robust, backporting to 2.2.x should be trivial, so I shouldn't worry about 2.2 lagging behind in this respect.
> Now the question: I've written a quick and dirty module that simply > modifies the registers...it APPEARS to work, but i can't tell on a > CPU point of view because the MCR's are write-only, and i can't read > them back to make sure they wrote right (is ther some other way? > does 'wrmsr' return a value i haven't found yet?) .. However, are > there any tests i can run on X to find out if it really is working? > i tried x11perf with and without the module loaded, but it appears > to run about the same each run.. is there any other tests? will > x11perf even show an improvement?
The most useful benchmark is one that blits images to the screen. So one with pixmap or SHM XImage blitting should show the difference quite nicely.
> also, what is the best setting for the X linear framebuffer? > writecombining for stacks? strings? both? neither?
Stacks? I can't imagine putting a stack in the framebuffer memory. Just strings would be good enough, although I see no harm in both. Frankly, I don't know what the distinction really is. I can guess what stacks are (well, I *know* what they are, but IDT may mean something odd, though I doubt it). I suppose by "strings" they really mean "all other accesses other than stacks". You tell me.
> I have a matrox Mystique in my test machine, with 3 memory addresses > listed in /proc/pci, 0xe0000000 [0xe0000008], 0xe1000000, and > 0xe08000000. X perorts that Liner Framebuffer at 0xe0000000, and > MMIO region and 0xe1000000...which region, or both, should be set > up? (or, tell me to shut up and ask the X people ;)
Just the linear framebuffer. Don't even think of making the MMIO region write-combining. That's the cards register set mapped into memory. Many register sets care about the order of writes. Write combining rearranges the order of writing. Besides, fiddling the MMIO registers is not time-critical anyway.
BTW: what's reported as being at 0xe08000000 ? Is that by any chance the linear frambuffer mapped for big endian CPUs?
One thing to watch out for: note how the linear framebuffer is listed as "0xe0000000 [0xe0000008]". This may mean the first 8 bytes of the frame buffer are "special" (like contain magic registers). If you have problems when setting this region to write-combining, try adding a subsequent "uncachable" region starting at 0xe0000000 for one page (4 kBytes). Usually linear framebuffers with embedded MMIO registers have them at the end of the framebuffer, not at the beginning, so this may be a furphy. Don't worry about it unless it presents a problem.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |