lkml.org 
[lkml]   [2013]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v4 5/7] cpufreq: Calculate number of busy CPUs
    Date
    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.


    \
     
     \ /
      Last update: 2013-06-20 00:41    [W:4.231 / U:0.152 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site