[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 5 May 2007 02:41:20 +0200
From: Segher Boessenkool <segher@...nel.crashing.org>
To: linas@...tin.ibm.com (Linas Vepstas)
Cc: Scott Wood <scottwood@...escale.com>, netdev@...r.kernel.org,
linuxppc-dev@...abs.org, jgarzik@...ox.com
Subject: Re: [PATCH v2] gianfar: Add I/O barriers when touching buffer descriptor ownership.
>> Well, Segher doesn't want me to use iobarrier (because it's not I/O).
>> Andy doesn't want me to use wmb() (because it's sync). I don't think
>> something like gfar_wmb() would be appropriate. So the remaining
>> options are either eieio(),
>
> ? Just curious... the original intent of eieio was to order I/O,
> such as MMIO; it has no effect on memory that isn't marked
> cache-inhibited or write-trhough or guarded. Has this changed?
eieio orders all accesses to address space that is WIMG=1xxx
or WIMG=x1x1; separately, it orders stores to address space
that is WIMG=001x.
> I guess I haven't kept up with the times ... is eieio now
> being used to provide some other kind of barrier?
Nothing changed.
> Is eieio providing some sort of SMP synchronization side-effect?
It orders stores to "well-behaved" memory yes.
> Point being: if Segher doesn't let you "use iobarrier (because
> it's not I/O)", then I don't understand why eieio would work (since
> that's for io only).
iobarrier() is a kernel-level primitive, meant for ordering
I/O only, as its name indicates. eieio is a CPU insn that
orders stores to main memory (amongst other things), not that
its name would tell you.
Segher
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists