On Tue, Feb 25, 2014 at 09:50:47AM +0800, Alex Shi wrote: > Old code considers the bias in source/target_load already. but still > use imbalance_pct as last check in idlest/busiest group finding. It is > also a kind of redundant job. If we bias imbalance in source/target_load, > we'd better not use imbalance_pct again. > > After cpu_load array removed, it is nice time to unify the target bias > consideration. So I remove the imbalance_pct from last check and add the > live bias using. > > On wake_affine, since all archs' wake_idx is 0, current logical is just > want to prefer current cpu. so we follows this logical. Just renaming the > target_load/source_load to wegithed_cpuload for more exact meaning. > Thanks for reminding from Morten! >
So this patch is weird.. So the original bias in the source/target load is purely based on actual load figures. It only pulls-down/pulls-up resp. the long term avg with a shorter term average; iow. it allows the source to decrease faster and the target to increase faster, giving a natural inertia (ie. a resistance to movement). Therefore this gives rise to a conservative imbalance. Then at the end we use the imbalance_pct thing as a normal hysteresis control to avoid the rapid state switching associated with a single control point system. You completely wreck that, you also don't give a coherent model back. The movement of imbalance_pct into target_load() doesn't make sense to me either; it's an (expensive) no-op afaict. Seeing how: 100 * source_load() < imb_pct * target_load() is very much equal to: source_load() < (imb_pct * target_load()) / 100; Except you get to do that div all over the place. It also completely muddles the fact that its a normal hysteresis control. Not a load bias. A fixed bias can never replace the inertial control we had; it doesn't make sense as a replacement. Not to mention you seem to ignore all concerns wrt the use of longer term averages for the bigger domains. Now I'm all for removing code; and so far the numbers aren't bad; but I don't like the complete muddle you make of things at all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
