[lkml]   [1998]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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

> Now the question: I've written a quick and dirty module that simply
> modifies the 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.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:46    [W:0.043 / U:0.556 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site