On Wednesday, June 19, 2013 10:58:32 PM Lukasz Majewski wrote: > On Wed, 19 Jun 2013 11:01:07 -0700 > Dirk Brandewie <dirk.brandewie@xxxxxxxxx> wrote: > > > On 06/19/2013 10:12 AM, Lukasz Majewski wrote: > > > In the core governor code, per cpu load value is calculated. This > > > patch uses it to mark processor as a "busy" one, when load value is > > > higher than 90%. > > > > > > New cpufreq sysfs attribute is created (busy_cpus). It is read only > > > and provides information about number of actually busy CPU. > > > > > > > What is the intended use of this interface? > > The kernel API would be handy with boost managed by software (like it is > done with exynos) and with LAB governor. > > The intention is to have two save valves for boost: > > 1. Enable SW controlled boost only when we have just one busy CPU. > > 2. Use the Thermal subsystem to switch off SW managed boost when it > detects that SoC is overheating. > > The problem with 2 is that, the boost code is compiled in to the cpufreq > core (no CONFIG_BOOST flag). Thereof we cannot guarantee, that thermal > would be always enabled (the KConfig select option). > I think that thermal subsystem is a suitable place to disable SW boost > at emergency. However in my opinion this is not enough and precaution > defined at 1 is needed. > > I can remove exporting the "busy_cpu" sysfs attribute if you think, that > it would confuse userspace. Its purpose is mainly informational. > > > > > For drivers that have internal governors it will be misleading/wrong > > Would you be so kind and give me an example of such an internal > governor? > > Maybe I've overlooked some important information/usecase. Please look at intel_pstate.c. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
