@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. > 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. Now, if you disable it at high temperatures then its responsibility to enable it again. Which you are missing. > 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. > 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). -- 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
