public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: David Miller <davem@davemloft.net>,
	jeff@garzik.org, mingo@elte.hu, tglx@linutronix.de,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	torvalds@linux-foundation.org
Subject: Re: [patch] x86, voyager: fix ioremap_nocache()
Date: Wed, 30 Apr 2008 16:44:04 -0500	[thread overview]
Message-ID: <1209591844.3774.30.camel@localhost.localdomain> (raw)
In-Reply-To: <20080427160120.5788118f@laptopd505.fenrus.org>

On Sun, 2008-04-27 at 16:01 -0700, Arjan van de Ven wrote:
> On Sun, 27 Apr 2008 15:46:20 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Jeff Garzik <jeff@garzik.org>
> > Date: Sun, 27 Apr 2008 18:39:24 -0400
> > 
> > > I disagree with this semantics change.  A number of code places
> > > _and drivers_ GET IT RIGHT, and these are all broken now?
> > 
> > [ Note, James's patch that you quoted is about mapping DMA
> >   memory, in dma_declare_coherent_memory(), rather than devices.
> >   But I know what you are trying to talk about Jeff. :-) ]
> > 
> > Wrt. ioremap() semanics, it is important to realize that if
> > the implementation of this on x86 has been giving non-cached
> > I/O mappings out up until recently, you can expect that there
> > are hundreds of drivers that might now be broken.
> 
> it's even worse than that.
> 99% of the time it gave out uncached memory, but if the bios was iffy,
> it would suddenly give out something else.
> 
> The changes to ioremap() recently turned that into "100% uncached".
> For me, that's the right (because safe) behavior, exactly for the
> reason you mentioned: it's what happened in practice, and driver writers
> would assume that to happen.
> 
> Anything except uncached would just be insanity as default.
> (well the old "whatever mood the bios writer was in, usually uncached" is
> effectively uncached except for weird behaving boxes)

OK, but look; this is why you broke me.

The former meaning of ioremap() was give me whatever caching the mtrrs
set up (assuming you actually have mtrrs.  For voyager, we don't so it
always meant give me cached memory).

The change broke the QIC ioremap area because it absolutely *requires*
cached memory.   It drops performance on the Q720 SCSI cards because
caching was used essentially like write combining to reduce the
unbursted traffic across the MCA bus.

When the Voyagers were designed, the only way to get them better
performace with the slow bus technology was to do a massive amount of
caching, so they're optimised to the point where every element on the
voyager bus (sort of like the intel frontside bus) is a primary
participant in the caching algorithm, and this includes the MCA
controllers.  So for me, I want every invocation of ioremap to mean
ioremap_cached() otherwise I don't benefit from the added caches.

I can fully understand that bus technology has got worse in terms of
caching since the voyager heydays.  However, I'd rather not be penalised
for everyone else's hardware failings.  Since the old ioremap is only
used in the IORESOURCE_CACHABLE case for PCI, and since that used to
defer to the mtrr settings anyway, it probably does make sense to keep
it as ioremap_cache() as long as that still defers to the mtrr settings.

I suppose I could think about an ioremap platform override for voyager
since, by and large, ioremap_nocache() is the wrong thing on the
platform.

James



  reply	other threads:[~2008-04-30 22:29 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-27 20:51 Breakage caused by unreviewed patch in x86 tree James Bottomley
2008-04-27 20:53 ` David Miller
2008-04-27 21:48 ` [patch] x86, voyager: fix ioremap_nocache() Ingo Molnar
2008-04-27 22:05   ` James Bottomley
2008-04-27 22:36     ` Willy Tarreau
2008-04-27 22:41     ` Ingo Molnar
2008-04-27 23:18     ` Ingo Molnar
2008-04-27 23:31       ` David Miller
2008-04-28  0:31         ` Rik van Riel
2008-04-28  0:45           ` Al Viro
2008-04-28  0:52             ` H. Peter Anvin
2008-04-28  9:01         ` Alan Cox
2008-04-28  9:17           ` David Miller
2008-04-28  9:48             ` Adrian Bunk
2008-04-28 11:50             ` Ingo Molnar
2008-04-28  6:10       ` Christoph Hellwig
2008-04-28 16:55         ` H. Peter Anvin
2008-04-27 22:34   ` James Bottomley
2008-04-27 22:39     ` Jeff Garzik
2008-04-27 22:44       ` H. Peter Anvin
2008-04-27 22:46       ` David Miller
2008-04-27 22:52         ` H. Peter Anvin
2008-04-27 22:58           ` David Miller
2008-04-27 23:04             ` H. Peter Anvin
2008-04-30 20:35               ` Eric W. Biederman
2008-04-27 23:34           ` Jeff Garzik
2008-04-27 23:39             ` H. Peter Anvin
2008-04-27 22:53         ` Jeff Garzik
2008-04-27 22:56           ` H. Peter Anvin
2008-04-27 22:59             ` David Miller
2008-04-27 23:02             ` Jeff Garzik
2008-04-27 23:14               ` Arjan van de Ven
2008-04-27 23:01         ` Arjan van de Ven
2008-04-30 21:44           ` James Bottomley [this message]
2008-04-30 22:39             ` H. Peter Anvin
2008-04-27 23:01       ` Thomas Gleixner
2008-04-28 14:10       ` Arjan van de Ven
2008-04-28 14:29         ` James Bottomley
2008-04-28 15:07           ` Arjan van de Ven
2008-04-28 19:59             ` H. Peter Anvin
2008-04-27 22:00 ` Breakage caused by unreviewed patch in x86 tree H. Peter Anvin
2008-04-27 22:10   ` James Bottomley
2008-04-27 22:13     ` H. Peter Anvin
2008-04-27 22:18       ` James Bottomley
2008-04-27 22:31         ` H. Peter Anvin
2008-04-27 22:58 ` Arjan van de Ven
2008-04-27 23:00   ` David Miller
2008-04-27 23:07     ` Arjan van de Ven
2008-04-27 23:03   ` James Bottomley
2008-04-27 23:11     ` Arjan van de Ven
2008-04-27 23:17     ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1209591844.3774.30.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=arjan@infradead.org \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox