On 11/14/2012 03:13 AM, Hugh Dickins wrote:
Please, Ingo, stop trying to force this in ahead of time, yet again. People are still reviewing and comparing competing solutions. Maybe this latest will prove to be closest to the right answer, maybe it will not. It's, what, about two days old right now? If we had wanted to push in a good solution a little prematurely, we would surely have chosen Andrea's AutoNUMA months ago, despite efforts to block it; and maybe we shall still want to go that way.
As much as I would like to see NUMA stuff going upstream the day before yesterday, I have to agree with Hugh that we need to do things right. Having unreviewed (some of it NAKed) code sitting in tip.git and you trying to force it upstream is not the right way to go.
Please, forget about v3.8, cut this branch out of linux-next, and seek consensus around getting it right for v3.9.
I suspect that no matter how long we delay merging the NUMA placement code, we will always run into some kind of regression. I am not sure if a delay will buy us much. On the mm/ bits, there appears to be consensus already. Mel Gorman's patch series contains the nicest mm/ bits from autonuma and sched/numa, plus further improvements. Andrea has supported Mel's series, and Ingo is pulling code from it. That leads me to believe Mel's NUMA bits may be worth considering for 3.8. On top of that, we could place the policy code by Peter and Ingo, but as a nice reviewable patch series, not hidden away through various tip.git branches. Does a combination of Mel's NUMA mm/ bits and the policy code from Peter and Ingo sound reasonable? Mel, is that reasonable to you? Peter & Ingo, are you willing to rebase your policy code on top of Mel's mm/ patches? -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
