Thread (14 messages) flat view 14 messages, 2 authors, 2015-02-26

Re: [RFC][PATCH v2] sched/rt: Use IPI to trigger RT task push migration instead of pulling

From: Steven Rostedt <rostedt@goodmis.org>
Date: 2015-02-26 14:01:05
Also in: lkml

On Thu, 26 Feb 2015 14:47:54 +0100
Peter Zijlstra [off-list ref] wrote:
quoted
Thinking about this more, is it because a wmb just forces the CPU to
write everything before this before it writes anything after it. That
is, the writes themselves can happen at a much later time. Does a plain
mb() work the same way if there are no reads required?
No, neither smp_wmb nor smp_mb are required to flush the store buffers.
Heh, that's what I said :-)  "That is, the writes themselves can happen
at a much later time."
The only thing barriers do is guarantee order, this can be done by
flushing store buffers but it can also be done by making sure store
buffers flush writes in the 'right' order.

Nor does an rmb help anything with ordering against a possible store
buffer flush. Again rmb only guarantees two loads are issued in that
particular order, it doesn't disallow the CPU speculating the load at
all.
Yep understood.
quoted
What about using atomic_t?

Note, my latest code doesn't have any of this, but I just want to
understand the semantics of these operations a bit better.
Nope, atomic_t doesn't help here either. Atomics only make sure the RmW
cycle is atomic.
Crummy. ;-)
Note that even if wmb or mb did flush the store buffer, you would still
have a race here.
Oh, it wasn't that I meant to remove the race. I was just trying to
make that race smaller.

But this is all academic now, as my last version doesn't do any of this.

-- Steve
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help