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