Re: [PATCH 2/7] sched: Update rq clock on nohz CPU before settingfair group shares

[Frederic Weisbecker]

2013/4/9 Peter Zijlstra <peterz@xxxxxxxxxxxxx>:
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/