Messages in this thread | | | Subject | Re: Breakage caused by unreviewed patch in x86 tree | From | James Bottomley <> | Date | Sun, 27 Apr 2008 19:03:59 -0400 |
| |
On Sun, 2008-04-27 at 15:58 -0700, Arjan van de Ven wrote: > On Sun, 27 Apr 2008 16:51:25 -0400 > James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > This patch: > > > > commit 6371b495991debfd1417b17c2bc4f7d7bae05739 > > Author: Ingo Molnar <mingo@elte.hu> > > Date: Wed Jan 30 13:33:40 2008 +0100 > > > > x86: change ioremap() to default to uncached > > > > As far as I can tell went blindly into the x86 tree without being > > shared on any mailing list at all. How can something that completely > > alters the semantics of ioremap on x86 platforms go in without any > > review.
> it changed from "whatever coinflip you got" to "predictable outcome". > What you got before was uncached (most of the time), or if the bios was > creative, write combining. Or if the bios was broken in how it set up MTRR's, you could suddenly > get "cached".
My major complaint is the lack of review and notice, not the actual patch.
> When you're mapping device memory, uncached is the safe default.
Well, for certain device mailboxes, uncached does mean less performant. The voyager breakage was exceptional ... I expect other problems just to result in a loss of performance that caching gave by improving the bursting. If we're lucky, the PCI bridge cache might hide a lot of this.
> With the switch to PAT (and phasing out of MTRR), the kernel needs to pick one of the three > (cached, writecombining, uncached) since you can no longer really depend on MTRRs saving > your bacon there. > Drivers in general, with VERY few exceptions, want uncached. Any other choice would have been deadly... > > I'd like to ask you which one you would pick... you maintain a whole bunch of drivers as scsi maintainer, what would > you have picked? > The answer "whatever the MTRR set up" no longer holds ;(
I wouldn't have picked ... I'd have asked for input.
James
| |