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
| ||
|
Message-ID: <2ca6459c-8ef5-9593-e8c4-52907d35355a@arm.com> Date: Thu, 7 Dec 2017 16:55:25 +0100 From: Dietmar Eggemann <dietmar.eggemann@....com> To: Patrick Bellasi <patrick.bellasi@....com>, Viresh Kumar <viresh.kumar@...aro.org> Cc: linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>, Vincent Guittot <vincent.guittot@...aro.org>, Morten Rasmussen <morten.rasmussen@....com>, Juri Lelli <juri.lelli@...hat.com>, Todd Kjos <tkjos@...roid.com>, Joel Fernandes <joelaf@...gle.com> Subject: Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter On 12/07/2017 01:45 PM, Patrick Bellasi wrote: > Hi Viresh, > > On 07-Dec 10:31, Viresh Kumar wrote: >> On 30-11-17, 11:47, Patrick Bellasi wrote: [...] >> We posted some comments on V2 for this particular patch suggesting >> some improvements. The patch hasn't changed at all and you haven't >> replied to few of those suggestions as well. Any particular reason for >> that? > > You right, since the previous posting has been a long time ago, with > this one I mainly wanted to refresh the discussion. Thanks for > highlighting hereafter which one was the main discussion points. > > >> For example: >> - I suggested to get rid of the conditional expression in >> cpufreq_schedutil.c file that you have added. > > We can probably set flags to SCHED_CPUFREQ_IDLE (instead of resetting > them), however I think we still need an if condition somewhere. > > Indeed, when SCHED_CPUFREQ_IDLE is asserted we don't want to trigger > an OPP change (reasons described in the changelog). > > If that's still a goal, then we will need to check this flag and bail > out from sugov_update_shared straight away. That's why I've added a > check at the beginning and also defined it as unlikely to have not > impact on all cases where we call a schedutil update with runnable > tasks. > > Does this makes sense? IIRC, there was also this question of doing this not only in the shared but also in the single case ... [...]
Powered by blists - more mailing lists