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 15:58:38 +0100 |
| |
On Thu, 2009-11-26 at 15:09 +0100, Peter Zijlstra wrote: > On Thu, 2009-11-26 at 11:16 +0100, Mike Galbraith wrote: > > > 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... > > The patch is also poking at rq->clock without rq->lock held... not very > nice.
To the users on the remote runqueue, it doesn't matter, they always update before using, so will always have accurate time.
What bothers me is that I don't see what prevents a SCHED_IDLE task making a huge min_vruntime update on the remote CPU while you're queueing a sleeper here, who used to live over there, while you're reading.
But, they're all instantaneous values anyway, so I suppose memory speed is fine. It works... and I really doubt that the yet another paranoid barrier I just put in will make diddly spit difference, but I did just put an smp_rmb() there anyway to see with my own eyes ;-)
> Gah, I hate that we're doing migration things without holding both rq's, > this is making live so very interesting ;-)
Yes.
-Mike
| |