Thread (7 messages) 7 messages, 4 authors, 2008-06-12

Re: MMIO and gcc re-ordering issue

From: Nick Piggin <hidden>
Date: 2008-06-12 11:27:39
Also in: linux-arch, lkml

Possibly related (same subject, not in this thread)

On Thursday 12 June 2008 02:07, Jesse Barnes wrote:
On Tuesday, June 10, 2008 8:29 pm Nick Piggin wrote:
quoted
You mention strong ordering WRT spin_unlock, which suggests that
you would prefer to take option #2 (the current powerpc one): io/io
is ordered and io is contained inside spinlocks, but io/cacheable
in general is not ordered.
I was thinking it would be good for the weaker accessors, but now that I
think about it you could just use the new io_* barrier functions.

I didn't mean to imply that I wasn't in favor of the io/cacheable ordering
as well.
quoted
For any high performance drivers that are well maintained (ie. the
ones where slowdown might be noticed), everyone should have a pretty
good handle on memory ordering requirements, so it shouldn't take
long to go through and convert them to relaxed accessors.
Yep.  Thanks for working on this, Nick, it's definitely a good thing that
you're taking control of it. :)
Well, I really am just trying to help the kernel for everyone (and every
architecture). Performance for all architectures really is my #2 priority,
so if any arch becomes irrepearably slower under a proposal I would
go back to the drawing board.

I'll come up with a proposal in the form of an initial code+documentation
patch when I get some more time on it.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help