Le 27/08/2013 18:15, Jiri Hladky a écrit : > using the weights looks like a good solution to me. However, we need > to think if and how we should propagate the weight via the upper > levels of the hierarchy. So for example if you have a socket with 4 > cores and cores 0&1 and 2&3 share L2 cache than the question is if and > how the weight 1 for core 0 should propagate via L2 cache to core 1 > (with some reduced factor).
You just explained why I don't like weights. Some people will want to ignore L2, some won't. Specifying all this on the command-line would be horrible, and implementing it will be horrible too. > I think that --reverse option is much easier for the implementation > and for the clear requirement and understanding how the output should > look like. Implementing reverse bitmap_singlify() isn't so easy. Also "--reverse" would have a semantics that no users ever requested, it's only a workaround for your actual need ("ignore core0 if possible"). What if somebody laer comes with a machine where he wants to preferably ignore core 7 and maybe ignore core 11 too, because some special daemons are running there? We'd need to add --dont-reverse-but-ignore-some-cores-if-possible. Or what if somebody wants to ignore the first core but still get other cores in the normal order? I tend to think we should let the application handle these specific cases (finding what can be ignored while still having enough objects, and then calling distribute accordingly). Brice