[lkml]   [2012]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] x86,sched: Fix sched_smt_power_savings totally broken

    On Mon, January 9, 2012 15:46, Peter Zijlstra wrote:
    > On Mon, 2012-01-09 at 15:29 +0100, Vincent Guittot wrote:
    >> I'm also using sched_mc level for doing powersaving load balance on
    >> ARM platform and we have real benefits.
    > Right, I've never said that power aware balancing was without merit, I
    > know it matters (quite a lot for some).
    >> We might modify the way we choose between power or performance mode
    >> because it's not always a matter of gathering or spreading tasks on
    >> cpus but until we found a best interface it's the way to enable
    >> powersaving mode
    > Sure, it was the only interface available.
    > But I really want to get rid of the topology based knobs we have now,
    > preferably I even want to get rid of the multi-value thing.
    > pjt still needs to post his linsched rework *poke* *poke*, that should
    > give a good basis to rework most of this without regressing the world
    > and then some.
    > But even without that I think we can do better than we do currently.

    Perhaps it should be controlled by the CPU governor instead of being
    a separate knob? Because in the end it is about power saving and that
    is the CPU governor's role. So to me it seems that at least the policy
    should come from/via the CPU governor. It seems right that there is one
    place that controls both frequencies and active core count.

    I guess what happens now is that powersaving aware scheduling causes a
    core to become idle, with the CPU governor detecting that and putting
    the core to sleep. Maybe it should be the other way round, with the
    governor detecting that not all cores are needed and putting one to

    This way the scheduler can schedule optimally over the available cores
    for maximum performance. For some hardware it may also be much better
    to have multiple active cores at low voltage and frequency instead of
    fewer cores at high frequency, especially if more cache is available.
    To pick the right policy automatically this kind of information has to
    be known, and currently such kind of information seems to come from the
    cpuidle/cpufreq drivers.

    Having just one knob which chooses between gathering or spreading tasks
    is a good start. But in the end it seems core idling should be controlled
    automatically depending on the hardware and circumstances by something
    like a CPU governor. It probably should also be aware of IRQ balancing
    and making sure idle cores don't get any interrupts while there are active
    cores that could handle them.

    I know people weren't too happy with the current implementation of the
    CPU governors either. Didn't someone implement a proof of concept version
    of an improved governor a while ago? (Arjan?)



     \ /
      Last update: 2012-01-10 03:35    [W:0.023 / U:32.384 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site