Re: Breakage caused by unreviewed patch in x86 tree

[James Bottomley]

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@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > This patch:
> > 
> > commit 6371b495991debfd1417b17c2bc4f7d7bae05739
> > Author: Ingo Molnar <mingo@xxxxxxx>
> > 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/