On 09/20/10 02:33, Pádraig Brady wrote: > On a related note, I've been meaning to check > if mutexes in coreutils/sort are more stable > and/or fair to the system than spinlocks.
They ought to be fairer, though I'd expect there to be a significant performance price in some cases. I'm not sure what you mean by "stable" (surely this has nothing to do with stable sorting :-). It's a bit tricky, as some users prefer performance, others fairness, and the default can't satisfy everybody. > perhaps we should cap the > number of cores used to perhaps 8 given results like: > http://debbugs.gnu.org/cgi/bugreport.cgi?msg=49;filename=sort-amd-24way.png;att=1;bug=6600 > We would allow increasing up to the number of cores > available on the system by user specified values > (which currently only support decreasing from #cores). That result depends on the particular benchmark and platform, of course. Still, it might make sense to default to at most 8 for now, as you suggest; the documentation should say that that default might change of course. Another thought: the syntax for --parallel might be generalized to allow for fancier heuristics, e.g.: --parallel=50% would mean to use at most half the processors. This particular syntax would be similar to how --buffer-size acts.
