Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <20171030120709.GO4240@vireshk-i7>
References: <20171028095941.4773-1-joelaf@google.com> <20171028095941.4773-3-joelaf@google.com>
 <20171030120709.GO4240@vireshk-i7>
From:   Joel Fernandes <joelaf@google.com>
Date:   Mon, 30 Oct 2017 12:02:59 -0700
Message-ID: <CAJWu+opNBs2u2FbXBKGtYeW2ipR7o-NUCOA95zh3xo-pqmd5mw@mail.gmail.com>
Subject: Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle
To:     Viresh Kumar <viresh.kumar@linaro.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        "Rafael J . Wysocki" <rjw@rjwysocki.net>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        "Cc: Srinivas Pandruvada" <srinivas.pandruvada@linux.intel.com>,
        "Cc: Len Brown" <lenb@kernel.org>,
        "Cc: Juri Lelli" <juri.lelli@arm.com>,
        "Cc: Patrick Bellasi" <patrick.bellasi@arm.com>,
        "Cc: Steve Muckle" <smuckle@google.com>,
        "Cc: Brendan Jackman" <brendan.jackman@arm.com>,
        "Cc: Chris Redpath" <Chris.Redpath@arm.com>,
        "Cc: Atish Patra" <atish.patra@oracle.com>,
        "Cc: Dietmar Eggemann" <dietmar.eggemann@arm.com>,
        "Cc: Vincent Guittot" <vincent.guittot@linaro.org>,
        "Cc: Morten Ramussen" <morten.rasmussen@arm.com>,
        "Cc: Frederic Weisbecker" <fweisbec@gmail.com>,
        "Cc: Thomas Gleixner" <tglx@linutronix.de>,
        "Cc: EAS Dev" <eas-dev@lists.linaro.org>,
        "Cc: Android Kernel" <kernel-team@android.com>,
        Steven Rostedt <rostedt@goodmis.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Viresh,

On Mon, Oct 30, 2017 at 5:07 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 28-10-17, 02:59, Joel Fernandes wrote:
>> Updating CPU frequency on last dequeue of a CPU is useless. Because the
>> utilization since CPU came out of idle can increase till the last dequeue, this
>> means we are requesting for a higher frequency before entering idle which is
>> not very meaningful or useful. It causes unwanted wakeups of the schedutil
>> governor kthread in slow-switch systems resulting in large number of wake ups
>> that could have been avoided. In an Android application playing music where the
>> music app's thread wakes up and sleeps periodically on an Android device, its
>> seen that the frequency increases slightly on the dequeue and is reduced when
>> the task wakes up again. This oscillation continues between 300Mhz and 350Mhz,
>> and while the task is running, its at 300MHz the whole time. This is pointless.
>> Adding to that, these are unnecessary wake ups. Infact most of the time when
>> the sugov thread wakes up, all the CPUs are idle - so it can hurt power by
>> disturbing the cluster when it is idling.
>>
>> This patch prevents a frequency update on the last dequeue. With this the
>> number of schedutil governor thread wake ups are reduces more than 2 times
>> (1389 -> 527).
>>
>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>> Cc: Viresh Kumar <viresh.kumar@linaro.org>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Signed-off-by: Joel Fernandes <joelaf@google.com>
>> ---
>>  kernel/sched/fair.c  | 25 ++++++++++++++++++++++---
>>  kernel/sched/sched.h |  1 +
>>  2 files changed, 23 insertions(+), 3 deletions(-)
>
> So you are doing this only for CFS, isn't that required for RT/DL as
> well?

Yes I agree we should. I remember this patch from Patrick doing
something similar for RT:
https://patchwork.kernel.org/patch/9825461/

That patch prevents cpufreq update from dequeue_task_rt path since we
no longer would trigger it from update_curr_rt all the time. Is this
an acceptable solution for RT?

>
> Also, this more looks like a policy decision. Will it be better to
> put that directly into schedutil? Like this:
>
>         if (cpu_idle())
>                 "Don't change the freq";
>
> Will something like that work?

I thought about this and I think it wont work very well. In the
dequeue path we're still running the task being dequeued so the CPU is
not yet idle. What is needed here IMO is a notion that the CPU is
possibly about to idle and we can get predict that from the dequeue
path of the CFS class.

Also just looking at whether the CPU is currently idle or not in the
governor doesn't help to differentiate between say the dequeue path /
tick path. Both of which can occur when the CPU is not idle.

Any thoughts about this?

thanks,

- Joel

From 1582684234846900858@xxx Mon Oct 30 12:08:25 +0000 2017
X-GM-THRID: 1582495113361800894
X-Gmail-Labels: Inbox,Category Forums