Messages in this thread |  | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH v4 5/7] cpufreq: Calculate number of busy CPUs | Date | Thu, 20 Jun 2013 00:26:42 +0200 |
| |
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@gmail.com> 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.
|  |