linux-kernel - Re: [PATCH v2] sched/fair: update scale invariance of PELT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Apr 2017 11:46:48 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Rasmussen <Morten.Rasmussen@....com>,
        Yuyang Du <yuyang.du@...el.com>, Paul Turner <pjt@...gle.com>,
        Ben Segall <bsegall@...gle.com>
Subject: Re: [PATCH v2] sched/fair: update scale invariance of PELT

On 11 April 2017 at 11:12, Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, Apr 11, 2017 at 09:52:21AM +0200, Vincent Guittot wrote:
>
>> > > + } else if (!weight) {
>> > > +         if (sa->util_sum < (LOAD_AVG_MAX * 1000)) {
>> >
>> > But here I'm completely lost. WTF just happened ;-)
>> >
>> > Firstly, I think we want a comment on why we care about the !weight
>> > case. Why isn't !running sufficient?
>>
>> We track the time when the task is "really" idle but not the time that
>> the task spent to wait for running on the CPU. Running is used to
>> detect when the task is really running and how much idle time has been
>> lost while weight is used to detect when the task is back to sleep
>> state and when we have account the lost idle time.
>
> Huh? You're redefining what 'idle' means wrt. util_sum.
>
> util used to consider anything !running as idle. So this is the main
> trickery? I feel that deserves a comment of exceptional clarity.

So we still decay during runnable but !running state but we don't add
the lost idle time of the previous running step yet.
We wait the task to go back to sleep before applying the lost idle
time in order to not apply the decay of the lost idle time in the
middle of a run phase that has been preempted by RT task as an example

I will try to make a comment that will explain these details