lkml.org 
[lkml]   [2016]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 1/2] sched/fair: move cpufreq hook to update_cfs_rq_load_avg()
    From
    On Wed, Apr 13, 2016 at 6:05 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
    > On Wed, Apr 13, 2016 at 6:48 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
    >> On Wed, Apr 13, 2016 at 2:08 AM, Steve Muckle <steve.muckle@linaro.org> wrote:
    >>> On Tue, Apr 12, 2016 at 04:29:06PM +0200, Rafael J. Wysocki wrote:
    >>>> This is rather fundamental.
    >>>>
    >>>> For example, if you look at cpufreq_update_util(), it does this:
    >>>>
    >>>> data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
    >>>>
    >>>> meaning that it will run the current CPU's utilization update
    >>>> callback. Of course, that won't work cross-CPU, because in principle
    >>>> different CPUs may use different governors and therefore different
    >>>> util update callbacks.
    >>>
    >>> Will something like the attached (unfinished patches) work? It seems
    >>> to for me, but I haven't tested it much beyond confirming the hook is
    >>> working on remote wakeups.
    >>
    >> No, they are not sufficient.
    >>
    >> First of all, you need to take all of the governors into account and
    >> they all make assumptions about updates being run on the CPU being
    >> updated.
    >>
    >> That should be easy to take into account for ondemand/conservative,
    >> but intel_pstate is a different story.
    >>
    >>> I'm relying on the previous comment that it's up to cpufreq drivers to
    >>> run stuff on the target policy's CPUs if the driver needs that.
    >>
    >> That's not the case for the fast frequency switching though, which has
    >> to happen on the CPU running the code.
    >>
    >>> There's still some more work, fixing up some more smp_processor_id()
    >>> usage in schedutil, but it should be easy (trace, slow path irq_work
    >>> target).
    >>>
    >>>> If you want to do remote updates, I guess that will require an
    >>>> irq_work to run the update on the target CPU, but then you'll probably
    >>>> want to neglect the rate limit on it as well, so it looks like a
    >>>> "need_update" flag in struct update_util_data will be useful for that.
    >>>
    >>> Why is it required to run the update on the target CPU?
    >>
    >> The fast switching and intel_pstate are the main reason.
    >>
    >> They both have to write to registers of the target CPU and the code to
    >> do that needs to run on that CPU.
    >
    > And these two seem to be the only interesting cases for you, because
    > if you need to work for the worker thread to schedule to eventually

    s/work/wait/ (sorry)

    > change the CPU frequency for you, that will defeat the whole purpose
    > here.

    \
     
     \ /
      Last update: 2016-04-13 18:21    [W:3.240 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site