Re: [PATCH v7 0/8] Tunable sched_mc_power_savings=n

[Vaidyanathan Srinivasan]

* Mike Galbraith <efault@xxxxxx> [2009-01-08 09:06:48]:

> On Wed, 2009-01-07 at 21:05 +0530, Vaidyanathan Srinivasan wrote:
> 
> > sched_mc=2 depends on NEWIDLE but the wakeup biasing part will be
> > enabled even without this flag.  The power savings will be marginally
> > better than sched_mc=1 without NEWIDLE.  But the end user can have
> > that setup if they want to.
> 
> That implies to me that there should exist a flag SD_WAKEUP_BIAS or
> whatnot.  All settings should be visible.  Currently, sched_mc > 0 turns
> on NEWIDLE, which is visible, but 2 turns on this 'invisible to the
> ultimate low-level control interface' thing.

Having a feature flag for each power saving balance is possible but
will be an overkill since independent control of features at each
sched domain may not yield useful configurations.  The present power
saving heuristics that gets enabled at sched_mc=1 is primarily
controlled by SD_POWERSAVE_BALANCE but has side effects and can be
rendered ineffective by changing other SD flags.

We did consider having individual SD_flag for each of the power
savings functions, but that quickly lead to too many possible
configurations with most of them incorrect or ineffective.  In order
to improve the consumeability of the power saving features, we have
proposed to enhance the existing tunable with monotonically increasing
powersavings vs performance tradeoffs.  

I agree with the 'visibility' to low level interface that you have
pointed out.  It will be good to have flags showup at the low level
interface, but do end users like system administrators would want to
know and tune these flags?  It makes sense with the current set of
flags which depict important scheduler features, but power savings
related flags only further qualify or emphasise existing functions and
control points in the scheduler.  

In my opinion adding flags for each powersaving feature will add 
un-necessary complexity and may not be as useful to end users.

--Vaidy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/