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

Reply via email to