[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7489: [coreutils] over aggressive threads in sort

From: Paul Eggert
Subject: bug#7489: [coreutils] over aggressive threads in sort
Date: Fri, 03 Dec 2010 13:10:58 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.0.10

On 12/03/10 12:18, Chen Guo wrote:
> I'll try out Professor Eggert's suggestion, of switching to mutexes
> only at the top level merge.

I'm having second thoughts about that.  Yes, that'll prevent the
top-level merge (which is generating the actual output) from chewing
up CPU time.  But it already has that property, since it's outputting
to stdout.  And if second-level merges use mutexes, then the third-level
merges will spin.  We'll have to use mutexes at all levels, unless
I'm missing something.

How about this idea instead.  Keep using spin locks everywhere, but
have the top-level merge output to memory, as the lower merges already
do.  The main thread can wait for the top level merge to finish and
then generate output.  That way, none of the merges will have to wait
on an output pipe (or a slow output file).

Either option (either switch to mutexes everywhere, or have the top-level
merge go to memory) should work.  Perhaps we should try both and benchmark

reply via email to

[Prev in Thread] Current Thread [Next in Thread]