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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 1 Nov 2017 12:35:37 -0700
From:   Steve Muckle <smuckle@...gle.com>
To:     Joel Fernandes <joelaf@...gle.com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Cc: Srinivas Pandruvada" <srinivas.pandruvada@...ux.intel.com>,
        "Cc: Len Brown" <lenb@...nel.org>,
        "Cc: Juri Lelli" <juri.lelli@....com>,
        "Cc: Patrick Bellasi" <patrick.bellasi@....com>,
        "Cc: Brendan Jackman" <brendan.jackman@....com>,
        "Cc: Chris Redpath" <Chris.Redpath@....com>,
        "Cc: Atish Patra" <atish.patra@...cle.com>,
        "Cc: Dietmar Eggemann" <dietmar.eggemann@....com>,
        "Cc: Vincent Guittot" <vincent.guittot@...aro.org>,
        "Cc: Morten Ramussen" <morten.rasmussen@....com>,
        "Cc: Frederic Weisbecker" <fweisbec@...il.com>,
        "Cc: Thomas Gleixner" <tglx@...utronix.de>,
        "Cc: EAS Dev" <eas-dev@...ts.linaro.org>,
        "Cc: Android Kernel" <kernel-team@...roid.com>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to
 idle

On 10/30/2017 12:02 PM, Joel Fernandes wrote:
>> 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?

Also if it really is the case that this bit of policy is universally 
desirable, I'd think it is better to do this in the scheduler and avoid 
a needless trip through a fn pointer out to schedutil for performance 
reasons.

Powered by blists - more mailing lists