diff options
| author | Chen Guo <chenguo4@ucla.edu> | 2010-12-06 00:15:42 -0800 |
|---|---|---|
| committer | Paul Eggert <eggert@cs.ucla.edu> | 2010-12-11 00:29:13 -0800 |
| commit | 621876ff446885d32922f34681790581c994f9a5 (patch) | |
| tree | e279f95ce07f9d267e14a8e09f79ae31622e3f02 /NEWS | |
| parent | 195c455d0ae3884ab2d9680ac3043aa36e9c8c3d (diff) | |
| download | coreutils-621876ff446885d32922f34681790581c994f9a5.tar.xz | |
sort: use mutexes, not spinlocks (avoid busy loop on blocked output)
Running a command like this on a multi-core system
sort < big-file | less
would peg all processors at near 100% utilization.
* src/sort.c: (struct merge_node) Change member lock to mutex.
All uses changed.
* tests/Makefile.am (XFAIL_TESTS): Remove definition, now that
this test passes once again. I.e., the sort-spinlock-abuse test
no longer fails.
* NEWS (Bug reports): Mention this.
Reported by DJ Lucas in http://debbugs.gnu.org/7489.
Diffstat (limited to 'NEWS')
| -rw-r--r-- | NEWS | 5 |
1 files changed, 5 insertions, 0 deletions
@@ -13,6 +13,11 @@ GNU coreutils NEWS -*- outline -*- sort -u with at least two threads could attempt to read through a corrupted pointer. [bug introduced in coreutils-8.6] + sort with at least two threads and with blocked output would busy-loop + (spinlock) all threads, often using 100% of available CPU cycles to + do no work. I.e., "sort < big-file | less" could waste a lot of power. + [bug introduced in coreutils-8.6] + ** New features split accepts the --number option to generate a specific number of files. |