> So I should have just deleted all patches, for none of them has a > changelog. >
It is my bad to not make changelogs in patches. The v2 has them, but I should have made them since always. > So all this cc crap only hooks into and modifies fair.c behaviour. There > is absolutely no reason it should live anywhere else except fair.c > > Secondly, the very last thing we need is more CONFIG_ goo, and you > sprinkle #ifdef around like it was gold dust. > Aggreed. I will change these. > Thirdly, wth is wrong with the current per-task runtime accounting and > why can't you extend/adapt that instead of duplicating the lot. > Sure. As you and Vincent said, CC will take a ride of current tracking codes instead of duplicating. > Fourthly, I'm _never_ going to merge anything that hijacks the load > balancer and does some random other thing. There's going to be a single > load-balancer full stop. > > Many people have expressed interest in a packing balancer (vs the > spreading we currently default to). Some have even done patches. > At the same time it seems very difficult to agree on _when_ packing > makes sense. That said, when we do packing we should do it driven by the > topology and policy, not by some compile time option. > I will make "Workload Consolidation" driven by topology and policy, essentially it is already so, but sure the codes are not completely clean in that regard. > Lastly, if you'd done your homework and actually read some of the > threads on the subject from say the past two years, you'd know pretty > much all that already. > > I'm not here to endlessly repeat myself and waste time staring at > unchangelogged patches. > This will not happen again. > Anyway, there might or might not be useful ideas in there.. but its very > hard to tell one way or another. I think the above is mostly about "amenability" to scheduler codes. Apparently, I am not doing it right. Will send another version to make it less hard. Thanks for your time. Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/