From: Tejun Heo <htejun@gmail.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Arjan van de Ven <arjan@infradead.org>,
linux-pci@atrey.karlin.mff.cuni.cz, Greg KH <greg@kroah.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: question regarding cacheline size
Date: Thu, 07 Sep 2006 15:19:04 +0200 [thread overview]
Message-ID: <45001C48.6050803@gmail.com> (raw)
In-Reply-To: <20060907130401.GO2558@parisc-linux.org>
Matthew Wilcox wrote:
> On Thu, Sep 07, 2006 at 02:53:57PM +0200, Tejun Heo wrote:
>> The spec says that devices can put additional restriction on supported
>> cacheline size (IIRC, the example was something like power of two >= or
>> <= certain size) and should ignore (treat as zero) if unsupported value
>> is written. So, there might be need for more low level driver
>> involvement which knows device restrictions, but I don't know whether
>> such devices exist.
>
> That's nothing we can do anything about. The system cacheline size is
> what it is. If the device doesn't support it, we can't fall back to a
> different size, it'll cause data corruption. So we'll just continue on,
> and devices which live up to the spec will act as if we hadn't
> programmed a cache size. For devices that don't, we'll have the quirk.
For MWI, it will cause data corruption. For READ LINE and MULTIPLE, I
think it would be okay. The memory is prefetchable after all. Anyways,
this shouldn't be of too much problem and probably can be handled by
quirks if ever needed.
> Arguably devices which don't support the real system cacheline size
> would only get data corruption if they used MWI, so we only have to
> prevent them from using MWI; they could use a different cacheline size
> for MRM and MRL without causing data corruption. But I don't think we
> want to go down that route; do you?
Oh yeah, that's what I was trying to say, and I don't want to go down
that route. So, I guess this one is settled.
Thanks.
--
tejun
next prev parent reply other threads:[~2006-09-07 13:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-07 8:31 question regarding cacheline size Tejun Heo
2006-09-07 11:11 ` Matthew Wilcox
2006-09-07 11:20 ` Tejun Heo
2006-09-07 12:07 ` Russell King
2006-09-07 12:23 ` Matthew Wilcox
2006-09-07 12:33 ` Arjan van de Ven
2006-09-07 12:40 ` Matthew Wilcox
2006-09-07 12:53 ` Tejun Heo
2006-09-07 13:04 ` Matthew Wilcox
2006-09-07 13:19 ` Tejun Heo [this message]
2006-09-07 15:21 ` Grant Grundler
2006-09-07 15:47 ` Tejun Heo
2006-09-07 16:00 ` Jeff Garzik
2006-09-07 17:00 ` Matthew Wilcox
2006-09-07 16:04 ` Jeff Garzik
2006-09-22 23:47 ` Grant Grundler
2006-09-07 13:30 ` Jeff Garzik
2006-09-07 13:10 ` Russell King
2006-09-07 13:01 ` Arjan van de Ven
2006-09-07 13:02 ` Russell King
2006-09-07 11:59 ` linux-os (Dick Johnson)
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=45001C48.6050803@gmail.com \
--to=htejun@gmail.com \
--cc=arjan@infradead.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=matthew@wil.cx \
/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