sort: do not generate thousands of subprocesses for 16-way merge
authorPaul Eggert <eggert@cs.ucla.edu>
Fri, 17 Dec 2010 06:31:56 +0000 (22:31 -0800)
committerPaul Eggert <eggert@cs.ucla.edu>
Fri, 17 Dec 2010 06:32:06 +0000 (22:32 -0800)
commit8e81a99c2690a5a8e3a3449e9c4f440738e0cac9
tree81978ebc6cb1b584d303d5b91bdc96bce31b6172
parent1b31ce6982a9151d9dfe2ea3595ad7595cb9ca86
sort: do not generate thousands of subprocesses for 16-way merge

Without this change, tests/misc/sort-compress-hang would consume
more than 10,000 process slots on my RHEL 5.5 x86-64 server,
making it likely for other applications to fail due to lack of
process slots.  With this change, the same benchmark causes 'sort'
to consume at most 19 process slots.  The change also improved
wall-clock time by 2% and user+system time by 14% on that benchmark.
* NEWS: Document this.
* src/sort.c (MAX_PROCS_BEFORE_REAP): Remove.
(reap_exited): Renamed from reap_some; this is a more accurate name,
since "some" incorrectly implies that it reaps at least one process.
All uses changed.
(reap_some): New function: it *does* reap at least one process.
(pipe_fork): Do not allow more than NMERGE + 2 subprocesses.
(mergefps, sort): Omit check for exited processes: no longer needed,
and anyway the code consumed too much CPU per line when 2 < nprocs.
NEWS
src/sort.c