Messages in this thread | | | Date | Thu, 27 Jun 2013 16:42:04 +0200 | From | Lukasz Majewski <> | Subject | Re: [PATCH v4 5/7] cpufreq: Calculate number of busy CPUs |
| |
On Thu, 27 Jun 2013 16:46:44 +0530, Viresh Kumar wrote: > @Rafael: We need you to jump into this discussion now, I don't > have a good idea about what we should do :) > > On 27 June 2013 16:28, Lukasz Majewski <l.majewski@samsung.com> wrote: > > Do you have any idea of how to precisely set the load threshold? > > I thought we are talking about cpu being in idle state.
If we _drop_ the idea with thermal subsystem to disable the boost, the logic as far as I've understood shall here be as follow:
Only enable BOOST when one CPU load > THRESHOLD_MAX and other CPUs < THRESHOLD_MIN
THRESHOLD_MIN & THRESHOLD_MAX are SoC specific.
In my opinion the above constrain imposes policy to the cpufreq driver.
> > > As a side note: > > > > I've thought about this patch for some time and for me it looks > > like we are mixing policy (number of busy CPUs) with abilities, > > which shall be provided by the driver (boost). > > Additionally, we can only roughly "estimate" [*] when boost shall > > run and when it shall be turned off. > > This is another problem in the patch you sent. User would simply > enable or disable boost feature from userspace only once.
The above statement is definitely true for Intel. There HW manage the frequency.
> > Now, if you disable it at high temperatures then its responsibility > to enable it again. Which you are missing.
So thermal or "other solution" [*] shall disable boost when overheated and enable it back when things cool down.
[*] @ Viresh & Rafael do you have any idea about the "other solution" here?
> > > I think that, we shall leave this management [*] to the thermal > > framework. This framework is designed exactly to protect from over > > heating (it uses the same freq_table for passive CPU cooling) with > > several trip points -> e.g. 40 deg (disable boost), 75 deg (impose > > max freq as 1.0 GHz to cool down, 90 deg (shutdown immediately). > > Please refer to PATH v4 7/7. > > There might be platforms where overheating isn't a issue with boost, > if it is only enabled while only one cpu is in use.
Could you elaborate more on this?
I thought, that with multi core one needs to keep itself inside power/thermal dissipation envelope.
> > > Unfortunately, since we dropped Kconfig flag for BOOST we cannot > > impose "select THERMAL_FRAMEWORK", when flag for BOOST is enabled at > > Kconfig. > > Not a big deal, we can get that in if required. > > > Ideally kernel shall not even build when CONFIG_CPUFREQ_BOOST > > Kconfig flag is set and thermal for target architecture is not > > correctly configured (including proper trip points).
This would prevent situation when somebody made a mistake and had enabled boost, but for some reason had forgotten to configure/enable thermal subsystem.
Moreover Kconfig's CONFIG_CPUFREQ_BOOST flag would indicate that user enabled boost for some reason and he/she (presumably) knows what is doing.
-- Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
| |