lkml.org 
[lkml]   [2014]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCHC 3/3] sched/fair: use the idle state info to choose the idlest cpu
    On Thu, 17 Apr 2014, Daniel Lezcano wrote:

    > On 04/17/2014 05:53 PM, Nicolas Pitre wrote:
    > > On Thu, 17 Apr 2014, Daniel Lezcano wrote:
    > >
    > > > Ok, refreshed the patchset but before sending it out I would to discuss
    > > > about
    > > > the rational of the changes and the policy, and change the patchset
    > > > consequently.
    > > >
    > > > What order to choose if the cpu is idle ?
    > > >
    > > > Let's assume all cpus are idle on a dual socket quad core.
    > > >
    > > > Also, we can reasonably do the hypothesis if the cluster is in low power
    > > > mode,
    > > > the cpus belonging to the same cluster are in the same idle state (putting
    > > > apart the auto-promote where we don't have control on).
    > > >
    > > > If the policy you talk above is 'aggressive power saving', we can follow
    > > > the
    > > > rules with decreasing priority:
    > > >
    > > > 1. We want to prevent to wakeup the entire cluster
    > > > => as the cpus are in the same idle state, by choosing a cpu in
    > > > => shallow
    > > > state, we should have the guarantee we won't wakeup a cluster (except if
    > > > no
    > > > shallowest idle cpu are found).
    > >
    > > This is unclear to me. Obviously, if an entire cluster is down, that
    > > means all the CPUs it contains have been idle for a long time. And
    > > therefore they shouldn't be subject to selection unless there is no
    > > other CPUs available. Is that what you mean?
    >
    > Yes, this is what I meant. But also what I meant is we can get rid for the
    > moment of the cpu topology and the coupling idle state because if we do this
    > described approach, as the idle state will be the same for the cpus belonging
    > to the same cluster we won't select a cluster down (except if there is no
    > other CPUs available).

    CPU topology is needed to properly describe scheduling domains. Whether
    we balance across domains or pack using as few domains as possible is a
    separate issue. In other words, you shouldn't have to care in this
    patch series.

    And IMHO coupled C-state is a low-level mechanism that should remain
    private to cpuidle which the scheduler shouldn't be aware of.

    > > > 2. We want to prevent to wakeup a cpu which did not reach the target
    > > > residency
    > > > time (will need some work to unify cpuidle idle time and idle task run
    > > > time)
    > > > => with the target residency and, as a first step, with the idle
    > > > => stamp,
    > > > we can determine if the cpu slept enough
    > >
    > > Agreed. However, right now, the scheduler does not have any
    > > consideration for that. So this should be done as a separate patch.
    >
    > Yes, I thought as a very first step we can rely on the idle stamp until we
    > unify the times with a big comment. Or I can first unify the idle times and
    > then take into account the target residency. It is to comply with Rafael's
    > request to have the 'big picture'.

    I agree, but that should be done incrementally. Even without this
    consideration, what you proposed is already an improvement over the
    current state of affairs.


    Nicolas


    \
     
     \ /
      Last update: 2014-04-17 18:41    [W:7.661 / U:0.204 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site