2013/4/9 Peter Zijlstra <[email protected]>: > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
