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


    \
     
     \ /
      Last update: 2013-06-27 18:21    [W:3.666 / U:1.784 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site