On Thu, Oct 18, 2018 at 9:50 AM Ingo Molnar <mi...@kernel.org> wrote: > > > * Rafael J. Wysocki <raf...@kernel.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