lkml.org 
[lkml]   [2008]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[RFC v1] Tunable sched_mc_power_savings=n
    Hi,

    The existing power saving loadbalancer CONFIG_SCHED_MC attempts to run
    the workload in the system on minimum number of CPU packages and tries
    to keep rest of the CPU packages idle for longer duration. Thus
    consolidating workloads to fewer packages help other packages to be in
    idle state and save power.

    echo 1 > /sys/devices/system/cpu/sched_mc_power_savings is used to
    turn on this feature.

    When enabled, this tunable would influence the loadbalancer decision
    in find_busiest_group(). Two parameters are extracted at the this
    time. group_leader is the group that is almost full and has just
    enough capacity to pull few (one) tasks while group_min is the group
    that has too few tasks and if we can move them to group_leader, then
    this group can go completely idle.

    The default criteria to select group_leader and group_min would catch
    long running threads on various packages and pull them to single
    package. The group_capacity limits the number of tasks that is being
    pulled and we are expected to have one task per core in a package and
    all the core in a package are loaded.

    This default criteria for selection when sched_mc_power_savings=1 has
    a good balance of power savings and least performance impact. The
    conservative approach taken towards consolidation makes the selection
    criteria workload dependent. Long running steady state workloads are
    placed correct, but not bursty workload.

    The idea being proposed is to enhance the tunable with varied degrees
    of consolidation that can work best for different workload
    characteristics. echo 2 > /sys/.../sched_mc_power_savings could
    enable more aggressive consolidation than the default.

    I am presently working on different criteria that can help consolidate
    different types of workload with varied degrees of power savings and
    performance impact.

    Advantages:

    * Enterprise workloads on large hardware configurations may need
    aggressive consolidation strategy
    * Performance impact on server is different from desktop or laptops.
    Interactivity is less of a concern on large enterprise servers while
    workload response times and performance per watt is more significant
    * Aggressive power savings even with marginal performance penalty is
    is a useful tunable for servers since it may provide good
    performance-per-watt at low utilisation
    * This tunable can influence other parts of scheduler like wakeup
    biasing for overall task consolidation

    Proposed changes:

    * Add more values to sched_mc_power_savings tunable (bit flags?)
    * Enable different consolidation strategy based on the value
    * Evaluate different strategy against different workloads and design
    heuristics for auto tuning
    * Modify selection of group_leader by changing the spare capacity
    evaluation
    * Increase group capacity of the group leader to avoid pulling tasks
    away from group_leader within a short time
    * Choose different load_idx while evaluating and selecting the load
    * Use the sched_mc_power_savings settings outside of load balancer
    like in task wakeup biasing
    * Design power saving loadbalancer in combination with process wakeup
    biasing in order to consolidate bursty and short running jobs to
    less CPU packages in an idle or under-utilised system.

    Disadvantages:

    * More tunable settings will lead to sub-optimal performance if not
    exploited correctly. Once the tunable criteria is established and
    we have good heuristics, we can have a default setting that can
    automatically choose the right technique.

    I will send the changes in criteria and their impact in subsequent
    RFCs. I would like to solicit feedback on the overall idea and inputs
    from people who have already attempted similar changes.

    Thanks,
    Vaidy




    \
     
     \ /
      Last update: 2008-06-25 21:11    [W:2.133 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site