On Mon, Mar 19, 2012 at 04:06:43PM +0200, Avi Kivity wrote: > I agree with Peter on this, but perhaps it's because my app will take > all of 15 minutes to patch. Up front knowledge is better than the > kernel discovering it on its own. I agree for qemu those soft bindings are fine. But how you compute the statistical data is most difficult part, how you collect them not so important after all. The scheduler code Peter said is "that's not going to ever happen" took several weeks of benchmarking and several rewrites to actual materialize and be super happy about the core algorithm. If it's simplified and just loops over the CPUs is because when you do research and invent you can't waste time on actual implementation details that just slow you down on the next rewrite of the algorithm as you have to try again. So if my algorithms (abeit in a simplified form compared to a real full implementation) works better, not having the background scanning won't help Peter at all and you'll still be better off with AutoNUMA. When you focus only on the cost of collecting the information and no actual discussion was spent yet on how to compute or react to it, something's wrong... as that's the really interesting part of the code. The fact the autonuma_balance() is simplified implementation is still perfectly ok right now, as that's totally hidden kernel internal thing, not even affecting kABI. Can be improved any time. Plus it's not like it will backfire, it just won't be running as good as a full more complex implementation that takes into account all the runqueues. And implementating that won't be easy at all, there are simpler things that are more urgent at this point. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>