Messages in this thread | | | Date | Tue, 9 Apr 2013 15:21:49 +0200 | Subject | Re: [PATCH 2/7] sched: Update rq clock on nohz CPU before setting fair group shares | From | Frederic Weisbecker <> |
| |
2013/4/9 Peter Zijlstra <peterz@infradead.org>: > On Sat, 2013-04-06 at 18:45 +0200, Frederic Weisbecker wrote: >> Because we may update the execution time (sched_group_set_shares()-> >> update_cfs_shares()->reweight_entity()->update_curr()) before >> reweighting the entity after updating the group shares and this >> requires >> an uptodate version of the runqueue clock. Let's update it on the >> target >> CPU if it runs tickless because scheduler_tick() is not there to >> maintain >> it. > > Same as the last comment, we should never rely on the tick to update > ->clock except for the work done by the tick itself.
Ok!
> > Therefore you seem to have found another missing clock update.
Yep, as in the other patches I believe, I'll reiterate that by removing that rely-on-tick assumption.
> The problem seems to be that we haven't been able to come up with a > sane debug framework for the ->clock updates. But we should have at > least one (and preferably no more) update_sched_clock() calls per > scheduler entry point.
I'll check if I can factorize some update_rq_clock() calls on some upper sched_class callback wrappers. Many of them have that update before calling the callbacks already. But there may be a few missing. I'll check the other sched entrypoints as well.
Also please check those two patches in my series, it's a draft for an rq clock debug framework. For now it's just a brainless stale clock check but that's a start:
* http://thread.gmane.org/gmane.linux.kernel/1470769/focus=1470786 * http://thread.gmane.org/gmane.linux.kernel/1470769/focus=1470750
| |