[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1157755773.31071.118.camel@localhost.localdomain>
Date: Sat, 09 Sep 2006 08:49:33 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Michael Chan <mchan@...adcom.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Segher Boessenkool <segher@...nel.crashing.org>,
Linux Kernel list <linux-kernel@...r.kernel.org>,
Paul Mackerras <paulus@...ba.org>,
Anton Blanchard <anton@...ba.org>
Subject: Re: TG3 data corruption (TSO ?)
> > I'd rather not have to do that, or even if I go that way, not have to
> > add that sync at all before the store and thus get back the few percent
> > of perfs lost due to those sync's on some heavy IO benchmarks.
> >
> Another way to fix this without requiring drivers to add all kinds of
> barriers in the driver code is to add a writel_sync() variant. So on
> powerpc, writel_sync() will have a sync before and after the write. On
> most other architectures, writel_sync() is the same as writel() if the
> ordering is guaranteed. We'll then convert tg3 and other drivers to use
> writel_sync() in places where they're needed.
I think the preferred approach for that sort of thing is to have writel
be the "sync" version and add special "relaxed" version. Now there have
been talks and debates about relaxed IOs but they generally map to
something different, typically IOs that are relaxed vs. DMA (PCI-X/PCIe
relaxed ordering options for example).
Adding yet another round of IO accessors sounds like a bit nasty to me,
driver writers will potentially not understand which ones to use etc...
Anyway, I think I'll let Anton and Paulus argue that one for now.
Cheers,
Ben.
-
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