[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060907152147.GA17324@colo.lackof.org>
Date: Thu, 7 Sep 2006 09:21:47 -0600
From: Grant Grundler <grundler@...isc-linux.org>
To: Tejun Heo <htejun@...il.com>
Cc: Matthew Wilcox <matthew@....cx>,
Arjan van de Ven <arjan@...radead.org>,
linux-pci@...ey.karlin.mff.cuni.cz, Greg KH <greg@...ah.com>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: question regarding cacheline size
On Thu, Sep 07, 2006 at 03:19:04PM +0200, Tejun Heo wrote:
...
> For MWI, it will cause data corruption. For READ LINE and MULTIPLE, I
> think it would be okay. The memory is prefetchable after all.
Within the context of DMA API, memory is prefetchable by the device
for "streaming" transactions but not for "coherent" memory.
PCI subsystem has no way of knowing which transaction a device
will use for any particular type of memory access. Only the
driver can embed that knowledge.
> 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.
hrm...if the driver can put a safe value in cachelinesize register
and NOT enable MWI, I can imagine a significant performance boost
if the device can use MRM or MRL. But IMHO it's up to the driver
writers (or other contributors) to figure that out.
Current API (pci_set_mwi()) ties enabling MRM/MRL with enabling MWI
and I don't see a really good reason for that. Only the converse
is true - enabling MWI requires setting cachelinesize.
hth,
grant
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists