[lkml]   [2009]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 8/15] sched: Add parameter sched_mn_power_savings to control MN domain sched policy
    On Mon, Aug 24, 2009 at 04:56:18PM +0200, Peter Zijlstra wrote:
    > On Thu, 2009-08-20 at 15:39 +0200, Andreas Herrmann wrote:
    > > Signed-off-by: Andreas Herrmann <>
    > > ---
    > > +#ifdef CONFIG_SCHED_MN
    > > + if (!err && mc_capable())
    > > + err = sysfs_create_file(&cls->kset.kobj,
    > > + &attr_sched_mn_power_savings.attr);
    > > +#endif
    > *sigh* another crappy sysfs file
    > Guys, can't we come up with anything better than sched_*_power_saving=n?

    Thought this is a settled thing. At least there are already two
    such parameters. So using the existing convention is an obvious
    thing, no?

    > This configuration space is _way_ too large, and now it gets even
    > crazier.

    I don't fully agree.

    Having one control interface for each domain level is just one
    approach. It gives the user full control of scheduling policies.
    It just might have to be properly documented.

    In another mail Vaidy mentioned that

    "at some point we wanted to change the interface to
    sched_power_savings=N and and set the flags according to system

    But how you'll decide at which domain level you have to do power
    savings scheduling?

    Using sched_mn_power_savings=1 is quite different from
    sched_smt_power_savings=1. Probably, the most power you save if you
    switch on power saving scheduling on each domain level. I.e. first
    filling threads of one core, then filling all cores on one internal
    node, then filling all internal nodes of one socket.

    But for performance reasons a user might just want to use power
    savings in the MN domain. How you'd allow the user to configure that
    with just one interface? Passing the domain level to
    sched_power_savings, e.g. sched_power_savings=MC instead of the power
    saving level?

    Besides that, don't we have to keep the user-interface stable, i.e.
    stick to sched_smt_power_savings and sched_mc_power_savings?


    Operating | Advanced Micro Devices GmbH
    System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
    Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
    Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
    (OSRC) | Registergericht München, HRB Nr. 43632

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-08-25 08:27    [W:0.045 / U:3.940 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site