On Wed, Jul 09, 2014 at 09:07:53AM +0800, Yuyang Du wrote: > That is chalenging... Can someone (Peter) grant us a lock of the remote rq? :)
Nope :-).. we got rid of that lock for a good reason. Also, this is one area where I feel performance really trumps correctness, we can fudge the blocked load a little. So the sched_clock_cpu() difference is a strict upper bound on the rq_clock_task() difference (and under 'normal' circumstances shouldn't be much off). So we could simply use a timestamps from dequeue and one from enqueue, and use that. As to the remote subtraction, a RMW on another cacheline than the rq->lock one should be good; esp since we don't actually observe the per-rq total often (once per tick or so) I think, no? The thing is, we do not want to disturb scheduling on whatever cpu the task last ran on if we wake it to another cpu. Taking rq->lock wrecks that for sure.
pgpDjQSoRwkvS.pgp
Description: PGP signature
