[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <069bbd75-f1f8-f30b-cd2a-2f143a065c66@google.com>
Date: Thu, 7 Sep 2017 11:10:58 -0700
From: Steve Muckle <smuckle@...gle.com>
To: Joel Fernandes <joelaf@...gle.com>,
LKML <linux-kernel@...r.kernel.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Len Brown <lenb@...nel.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Viresh Kumar <viresh.kumar@...aro.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@....com>,
Patrick Bellasi <patrick.bellasi@....com>,
kernel-team@...roid.com
Subject: Re: [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on
rq that sleeps
On 09/07/2017 09:14 AM, Joel Fernandes wrote:
> I'm planning to rebase this series on Linus's master and post it
> again, but just checking any thoughts about it?
>
> Just to add more context, the reason for not updating the frequency:
>
> - When a last dequeue of a sleeping task happens, it is sufficient to
> update utilization without updating the frequency because if other
> CPUs are busy then their updates will consider the utilization of the
> idle CPU in the shared policy unless sufficient time has passed.
>
> - If the last dequeue of a sleeping task happens while all other CPUs
> in the cluster are idle, then the cluster will likely enter
> cluster-idle soon.
To clarify - when you say "last dequeue of a sleeping task happens"
above, you're referring to the dequeue of the last task running on the
CPU, correct? I.e. the CPU is about to go idle?
It's been a while since I've looked at this area so would like to hold
off for a rebased version to review in further detail. But I think the
concept is valid.
thanks,
steve
Powered by blists - more mailing lists