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@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
