linux-kernel - Re: [RFC PATCH 0/7] Introduce thermal pressure

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:   Thu, 18 Oct 2018 10:14:28 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Thara Gopinath <thara.gopinath@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Zhang, Rui" <rui.zhang@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Amit Kachhap <amit.kachhap@...il.com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Javi Merino <javi.merino@...nel.org>,
        Eduardo Valentin <edubezval@...il.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Quentin Perret <quentin.perret@....com>,
        ionela.voinescu@....com,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [RFC PATCH 0/7] Introduce thermal pressure

On Thu, Oct 18, 2018 at 9:50 AM Ingo Molnar <mingo@...nel.org> wrote:
>
>
> * Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> > > The only long term maintainable solution is to move all high level
> > > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c,
> > > which has been done to a fair degree already in the past ~2 years - but
> > > it's unclear to me to what extent this is true for thermal throttling
> > > policy currently: there might be more governor surgery and code
> > > reshuffling required?
> >
> > It doesn't cover thermal management directly ATM.
> >
> > The EAS work kind of hopes to make a connection in there by adding a
> > common energy model to underlie both the performance scaling and
> > thermal management, but it doesn't change the thermal decision making
> > part AFAICS.
> >
> > So it is fair to say that additional governor surgery and code
> > reshuffling will be required IMO.
>
> BTW., when factoring out high level thermal management code it might make
> sense to increase the prominence of the cpufreq code within the scheduler
> and organize it a bit better, by introducing its own
> kernel/sched/cpufreq/ directory and renaming things the following way:
>
>   kernel/sched/cpufreq.c                => kernel/sched/cpufreq/core.c
>   kernel/sched/cpufreq_schedutil.c      => kernel/sched/cpufreq/metrics.c
>   kernel/sched/thermal.c                => kernel/sched/cpufreq/thermal.c
>
> ... or so?
>
> With no change to functionality, this is just a re-organization and
> expansion/preparation for the bright future. =B-)

No disagreement here. :-)

Cheers,
Rafael