Skip to content
  • Patrick Bellasi's avatar
    sched/uclamp: Extend CPU's cgroup controller · 2480c093
    Patrick Bellasi authored
    
    
    The cgroup CPU bandwidth controller allows to assign a specified
    (maximum) bandwidth to the tasks of a group. However this bandwidth is
    defined and enforced only on a temporal base, without considering the
    actual frequency a CPU is running on. Thus, the amount of computation
    completed by a task within an allocated bandwidth can be very different
    depending on the actual frequency the CPU is running that task.
    The amount of computation can be affected also by the specific CPU a
    task is running on, especially when running on asymmetric capacity
    systems like Arm's big.LITTLE.
    
    With the availability of schedutil, the scheduler is now able
    to drive frequency selections based on actual task utilization.
    Moreover, the utilization clamping support provides a mechanism to
    bias the frequency selection operated by schedutil depending on
    constraints assigned to the tasks currently RUNNABLE on a CPU.
    
    Giving the mechanisms described above, it is now possible to extend the
    cpu controller to specify the minimum (or maximum) utilization which
    should be considered for tasks RUNNABLE on a cpu.
    This makes it possible to better defined the actual computational
    power assigned to task groups, thus improving the cgroup CPU bandwidth
    controller which is currently based just on time constraints.
    
    Extend the CPU controller with a couple of new attributes uclamp.{min,max}
    which allow to enforce utilization boosting and capping for all the
    tasks in a group.
    
    Specifically:
    
    - uclamp.min: defines the minimum utilization which should be considered
    	      i.e. the RUNNABLE tasks of this group will run at least at a
    	      minimum frequency which corresponds to the uclamp.min
    	      utilization
    
    - uclamp.max: defines the maximum utilization which should be considered
    	      i.e. the RUNNABLE tasks of this group will run up to a
    	      maximum frequency which corresponds to the uclamp.max
    	      utilization
    
    These attributes:
    
    a) are available only for non-root nodes, both on default and legacy
       hierarchies, while system wide clamps are defined by a generic
       interface which does not depends on cgroups. This system wide
       interface enforces constraints on tasks in the root node.
    
    b) enforce effective constraints at each level of the hierarchy which
       are a restriction of the group requests considering its parent's
       effective constraints. Root group effective constraints are defined
       by the system wide interface.
       This mechanism allows each (non-root) level of the hierarchy to:
       - request whatever clamp values it would like to get
       - effectively get only up to the maximum amount allowed by its parent
    
    c) have higher priority than task-specific clamps, defined via
       sched_setattr(), thus allowing to control and restrict task requests.
    
    Add two new attributes to the cpu controller to collect "requested"
    clamp values. Allow that at each non-root level of the hierarchy.
    Keep it simple by not caring now about "effective" values computation
    and propagation along the hierarchy.
    
    Update sysctl_sched_uclamp_handler() to use the newly introduced
    uclamp_mutex so that we serialize system default updates with cgroup
    relate updates.
    
    Signed-off-by: default avatarPatrick Bellasi <patrick.bellasi@arm.com>
    Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: default avatarMichal Koutny <mkoutny@suse.com>
    Acked-by: default avatarTejun Heo <tj@kernel.org>
    Cc: Alessio Balsini <balsini@android.com>
    Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Cc: Joel Fernandes <joelaf@google.com>
    Cc: Juri Lelli <juri.lelli@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Morten Rasmussen <morten.rasmussen@arm.com>
    Cc: Paul Turner <pjt@google.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Quentin Perret <quentin.perret@arm.com>
    Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
    Cc: Steve Muckle <smuckle@google.com>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Todd Kjos <tkjos@google.com>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Link: https://lkml.kernel.org/r/20190822132811.31294-2-patrick.bellasi@arm.com
    
    
    Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    2480c093