On Fri, May 23, 2008 at 04:40:21PM +1000, Paul Mackerras wrote:
> Nick Piggin writes:
>
> > Anyway, even if there were zero, then the point is still that you
> > implement that API, so you should either strongly order your
> > __raw_ and _relaxed then you can weaken your rmb, or you have to
> > st
Nick Piggin writes:
> Anyway, even if there were zero, then the point is still that you
> implement that API, so you should either strongly order your
> __raw_ and _relaxed then you can weaken your rmb, or you have to
> strengthen your rmb to match your weak read ops.
>
> Saying it doesn't matter
On Fri, May 23, 2008 at 02:53:21PM +1000, Paul Mackerras wrote:
> Nick Piggin writes:
>
> > There don't seem to actually be read*_relaxed calls that also use rmb
> > in the same file (although there is no reason why they might not appear).
> > But I must be thinking of are the raw_read accessors.
Nick Piggin writes:
> There don't seem to actually be read*_relaxed calls that also use rmb
> in the same file (although there is no reason why they might not appear).
> But I must be thinking of are the raw_read accessors. They aren't ordered
> on powerpc, and a few drivers appear to hope rmb() w
On Fri, May 23, 2008 at 12:14:41PM +1000, Paul Mackerras wrote:
> Nick Piggin writes:
>
> > More than one device driver does raw/relaxed io accessors and expects the
> > *mb functions to order them.
>
> Can you point us at an example?
Uh, I might be getting confused because the semantics are com
Nick Piggin writes:
> More than one device driver does raw/relaxed io accessors and expects the
> *mb functions to order them.
Can you point us at an example?
I don't think the semantics of the raw accessors are particularly well
defined (it's not even defined what endianness the data comes back
On Wed, 2008-05-21 at 17:32 +0200, Nick Piggin wrote:
> > We should already do all that's needed in our IO accessors no ?
>
> More than one device driver does raw/relaxed io accessors and expects
> the
> *mb functions to order them.
That's fishy... ok.
Ben.
___
On Wed, May 21, 2008 at 11:27:03AM -0400, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-05-21 at 16:10 +0200, Nick Piggin wrote:
> > Hi,
> >
> > I'm sure I've sent these patches before, but I can't remember why they
> > weren't merged. They still seem obviously correct to me.
>
> We should alre
On Wed, 2008-05-21 at 16:10 +0200, Nick Piggin wrote:
> Hi,
>
> I'm sure I've sent these patches before, but I can't remember why they
> weren't merged. They still seem obviously correct to me.
We should already do all that's needed in our IO accessors no ?
> --
>
> lwsync is explicitly define
Hi,
I'm sure I've sent these patches before, but I can't remember why they
weren't merged. They still seem obviously correct to me.
--
lwsync is explicitly defined not to have any effect on the ordering of
accesses to device memory, so it cannot be used for rmb(). sync appears
to be the only bar
On Thu, Aug 23, 2007 at 07:57:20PM +0200, Segher Boessenkool wrote:
> >>The powerpc kernel needs to have full sync insns in every I/O
> >>accessor in order to enforce all the ordering rules Linux demands.
> >>It's a bloody shame, but the alternative would be to make the
> >>barriers lots more expen
>>> Drivers are definitely using these __raw_ accessors, and from a quick
>>> look, they do appear to be hoping that *mb() is going to order access
>>> for
>>> them.
>>
>> Which drivers?
>
> There are maybe a dozen that use the raw accessors, and use non-smp_
> memory barriers. I just looked at dri
>> The powerpc kernel needs to have full sync insns in every I/O
>> accessor in order to enforce all the ordering rules Linux demands.
>> It's a bloody shame, but the alternative would be to make the
>> barriers lots more expensive. A third alternative would be to
>
> Well lots more expensive comp
On Wed, Aug 22, 2007 at 05:33:16AM +0200, Segher Boessenkool wrote:
> >>The I/O accessor functions enforce the necessary ordering
> >>already I believe.
> >
> >Hmm, I never followed those discussions last year about IO ordering,
> >and
> >I can't see where (if) it was documented anywhere :(
>
> T
On Wed, Aug 22, 2007 at 05:29:50AM +0200, Segher Boessenkool wrote:
> >>>If this isn't causing any problems maybe there
> >>>is some loigic we are overlooking?
> >>
> >>The I/O accessor functions enforce the necessary ordering
> >>already I believe.
> >
> >Ah, it looks like you might be right, IO s
>> The I/O accessor functions enforce the necessary ordering
>> already I believe.
>
> Hmm, I never followed those discussions last year about IO ordering,
> and
> I can't see where (if) it was documented anywhere :(
The comments in system.h weren't updated with the last fix, I think.
> It appea
>>> If this isn't causing any problems maybe there
>>> is some loigic we are overlooking?
>>
>> The I/O accessor functions enforce the necessary ordering
>> already I believe.
>
> Ah, it looks like you might be right, IO should appear to go in-order,
> in
> which case the rmb() would simply need t
On Tue, Aug 21, 2007 at 09:43:17PM +0200, Segher Boessenkool wrote:
> >> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
> >>-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
> >>"memory")
> >>+#define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> >> #define wmb()
On Tue, Aug 21, 2007 at 09:43:17PM +0200, Segher Boessenkool wrote:
> >> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
> >>-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
> >>"memory")
> >>+#define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> >> #define wmb()
On Tue, Aug 21, 2007 at 09:43:17PM +0200, Segher Boessenkool wrote:
> >> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
> >> -#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
> >> "memory")
> >> +#define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> >> #define
>> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
>> -#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
>> "memory")
>> +#define rmb() __asm__ __volatile__ ("sync" : : : "memory")
>> #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
>> #define read_barrier_d
> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
> -#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : : "memory")
> +#define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
> #define read_barrier_depends()
In the interest of completeness, I'll split these patches up and submit to
the powerpc dev list. Any discussion or ack/nack would be appreciated.
---
lwsync is defined to only order memory operations on cacheable memory.
A full sync appears to be the only barrier that will order all memory
loads i
23 matches
Mail list logo
