lkml.org 
[lkml]   [2008]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v4 1/7] sched: Framework for sched_mc/smt_power_savings=N
    * David Collier-Brown <David.Collier-Brown@Sun.COM> [2008-11-21 19:45:55]:

    > Vaidyanathan Srinivasan wrote:
    > > From: Gautham R Shenoy <ego@in.ibm.com>
    > >
    > > *** RFC patch of work in progress and not for inclusion. ***
    > >
    > > Currently the sched_mc/smt_power_savings variable is a boolean, which either
    > > enables or disables topology based power savings. This extends the behaviour of
    > > the variable from boolean to multivalued, such that based on the value, we
    > > decide how aggressively do we want to perform topology based powersavings
    > > balance.
    > >
    > > Variable levels of power saving tunable would benefit end user to match the
    > > required level of power savings vs performance trade off depending on the
    > > system configuration and workloads.
    > >
    > > This initial version makes the sched_mc_power_savings global variable to take
    > > more values (0,1,2).
    >
    > Might I suggest a dimensioned number rather than a relative one?
    > One might say that 100 represents the full power of a system, meaning
    > that all chips/cores are running at full speed, whereas 50 means that
    > the power system would attempt to halve the resources available, and
    > would return a value that represents the value that the power system
    > believes it has achieved. For example, if it could only reduce the
    > clock speed by 10%, on a old uniprocessor, it would return 90.

    Ideally we would like to have such a metric :) However practically
    the power savings and performance tradeoff depends on

    1) System configuration (topology, cpu type, cpu features)
    2) Workload -- memory bound, IO bound, cpu bound
    3) Environment -- system temperature

    and many more dimensions that we have not considered yet!

    What you are asking for may have been possible if the CPUs were very
    simple and performance and power directly corresponded to operating
    frequency. Modern CPUs have very widely varying operating
    characteristics that greatly depend on workload type. Hence deriving
    a metric for power vs performance tradeoff will be very inaccurate and
    useless.

    We may be able to design the framework in such a way that each level
    of settings will provide increasing levels of power savings with
    little or no performance impact (depending on the workload).

    Power consumption at sched_mc=0 > sched_mc=1 > sched_mc=2 but not in
    linear scale.

    Also, this is only one of the component of the power saving tunables.
    There are various governor settings and platform setting that may
    affect the power consumption.


    > An additional, second value it might return might be the power
    > reduction it believed it had achieved.

    Measuring the actual power being consumed will be useful for sys
    admins to choose the correct settings. However this is platform
    dependent and best left to the platform management tools as compared
    to generic scheduler.

    We would expect the end user to use the platform management tools to
    collect and trend the power consumption data and correlate with the
    power saving tunables to decide the best power vs performance
    tradeoffs.

    > These, by the way, are what my Tadpole GUI shows (;-)) so I'm just
    > following someone else's lead.

    Can you please provide more details. I could not get a google hit on
    the Tadpole GUI which is relevant to this discussion.

    Thanks,
    Vaidy


    \
     
     \ /
      Last update: 2008-11-22 19:05    [W:0.023 / U:59.148 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site