Messages in this thread | | | Date | Thu, 26 Feb 2015 09:00:55 -0500 | From | Steven Rostedt <> | Subject | Re: [RFC][PATCH v2] sched/rt: Use IPI to trigger RT task push migration instead of pulling |
| |
On Thu, 26 Feb 2015 14:47:54 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
> > 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.
> > 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
| |