Messages in this thread |  | | Subject | Re: [patch] sched: fix set_task_cpu() and provide an unlocked runqueue variant | | From | Mike Galbraith <> | | Date | Thu, 26 Nov 2009 11:16:18 +0100 |
| |
On Thu, 2009-11-26 at 10:35 +0100, Peter Zijlstra wrote: > On Thu, 2009-11-26 at 02:31 +0100, Mike Galbraith wrote: > > On Thu, 2009-11-26 at 02:01 +0100, Mike Galbraith wrote: > > > On Wed, 2009-11-25 at 19:27 +0100, Peter Zijlstra wrote: > > > > > > I've got to ask, what's that barrier for? > > > > > > It's a leftover from frustrated bug hunting. > > > > To be more specific, I put it there to ensure that min_vruntimes are > > stable. > > min_vruntime should only ever be poked at when holding the respective > rq->lock, even with a barrier a 64bit read on a 32bit machine can go all > funny.
Yeah, but we're looking at an unlocked runqueue. But never mind...
> > I figured that if try_to_wake_up() needs a barrier to look at > > task->state, I had better do the same for the runqueues. > > Ah, ttwu() has that barrier for another reason. The wmb in ttwu() is to > ensure the wakee sees the state of the waker at the time of waking. > > That is, its about ordering things like: > > > A B > > > my_cond = true; > wake_process(my_friend); > > while (!my_cond) > schedule(); > > > So that you can actually observe my_cond being true once you wakeup > (schedule acts as a mb() when it actually schedules).
(Ah! I think you actually made a wrinkle in grey-ware)
...ATM, I kinda wish I'd not gone off and read barriers.txt. It hasn't sunk in yet, but certainly has made me _paranoid as hell_ :-)
-Mike
|  |