lkml.org 
[lkml]   [2006]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-09-07 17:25    [W:0.068 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site