lkml.org 
[lkml]   [2017]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support
    From
    Date
    On 10/07/17 10:42, Viresh Kumar wrote:
    > On 10-07-17, 11:30, Peter Zijlstra wrote:
    >> On Sat, Jul 08, 2017 at 02:09:37PM +0200, Rafael J. Wysocki wrote:
    >>> Anyway, if everyone agrees that doing it in the core is the way to go (Peter?),
    >>> why don't you introduce a __weak function for setting policy->cur and
    >>> override it from your arch so as to call arch_set_freq_scale() from there?
    >>>
    >>
    >> So I'm terminally backlogged and my recent break didn't help any with
    >> that.
    >>
    >> I'm at a total loss as to what is proposed here and why we need it. I
    >> tried reading both the Changelog and patch but came up empty.
    >
    > Dietmar is proposing the implementation of arch_set_freq_scale() for ARM (32/64)
    > platforms here with following equation in drivers/base/arch_topology.c:
    >
    > scale = (cur_freq << SCHED_CAPACITY_SHIFT) / max_freq
    >
    > The only variable part here is "cur_freq" and he is looking for sane ways to get
    > that value in the arch_topology.c file, so he can use that in the above
    > equation. He tried to use cpufreq transition notifiers earlier but they block us
    > from using fast switching.
    >
    > What he is proposing now is a function:
    >
    > void arch_set_freq_scale(struct cpumask *cpus, unsigned long cur_freq,
    > unsigned long max_freq);
    >
    > which has to be called by someone after the frequency of the CPU is changed.
    >
    > Dietmar proposed that this be called by cpufreq core and Rafael was wondering if
    > the cpufreq drivers should call it. Dietmar's argument is that it will be used
    > for the entire ARM architecture this way and wouldn't lead to redundant core
    > across drivers.
    >
    > Hope I didn't confuse you more with this :)
    >

    Perfect summary, thanks Viresh!

    This is required for architectures (like arm/arm64) which do not have
    any other way to know about the current CPU frequency.

    X86 can do the frequency invariance support based on APERF/MPERF already
    today so it does not need the support from cpufreq.

    \
     
     \ /
      Last update: 2017-07-10 12:32    [W:4.324 / U:0.568 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site