Re: [RFC PATCH v2 0/7] Tunable sched_mc_power_savings=n

From: Vaidyanathan Srinivasan
Date: Wed Sep 10 2008 - 09:44:30 EST

* Andi Kleen <andi@xxxxxxxxxxxxxx> [2008-09-08 15:58:34]:

> > 1. Detailed documentation
> Messy code cannot be really made good with documentation. It's
> not that your patches are that messy, it's more that it makes
> something already overcomplicated even worse.
> > 2. Cleanup the group_min and group_leader stuff in
> > find_busiest_group()
> I think one issue is that there are general too many special cases
> that completely change the algorithm especially for power saving.
> Perhaps it would make sense to refactor the code a bit and then
> use different high level code paths for those? I assume that
> would make it all simpler and easier to understand.

Hi Andi,

I will try to refactor the code and see if it can look cleaner. Power
saving balance is actually just a corner case in general load_balance.
We will have to do default load_balance for performance each time we
enter this section of the scheduler, except when certain complex
conditions are met and we see an opportunity to save power. When that
window of opportunity to save power exist, the code will take
a different path and do things that will normally not be done by the
default load balancer logic.

I think we can split the statistics (load) computation part and the
decision part to separate functions and call the power save balance
conditions first and if there is no opportunity to save power, then
recommend the default load balancing decision.

> The other alternative would be to dynamically change the domains
> so that a generic graph walker without knowledge of power savings
> could DTRT in all cases. But I assume that would be much harder.

This option may not work because we will have to change the decision
only when a power saving opportunity exist. Hence more often the
power save balance code should just fall through into the default
balancer. Splitting them this way may add duplicate code in both the

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