On Wed, Jul 09, 2014 at 12:07:08PM -0700, bseg...@google.com wrote: > Peter Zijlstra <pet...@infradead.org> writes: > > > 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). > > Well, unless IRQ_TIME_ACCOUNTING or such is on, in which case you lose. > Or am I misunderstanding the suggestion?
If its on its still an upper bound, and typically the difference is not too large I think. Since clock_task is the regular clock minus some local amount, the difference between two regular clock reads is always a strict upper bound on clock_task differences. > Actually the simplest thing > would probably be to grab last_update_time (which on 32-bit could be > done with the _copy hack) and use that. Then I think the accuracy is > only worse than current in that you can lose runnable load as well as > blocked load, and that it isn't as easily corrected - currently if the > blocked tasks wake up they'll add the correct numbers to > runnable_load_avg, even if blocked_load_avg is screwed up and hit zero. > This code would have to wait until it stabilized again. The problem with that is that last_update_time is measured in clock_task, and you cannot transfer these values between CPUs. clock_task can drift unbounded between CPUs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
