GNU bug report logs -
#7489
[coreutils] over aggressive threads in sort
Previous Next
Reported by: DJ Lucas <dj <at> linuxfromscratch.org>
Date: Fri, 26 Nov 2010 19:40:02 UTC
Severity: normal
Tags: fixed
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Chen Guo wrote:
> Hi Professor Eggert,
> On Mon, Nov 29, 2010 at 11:16 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>> (for i in $(seq 12); do read line; echo $i; sleep .1; done
>> cat > /dev/null) < fifo &
>> (ulimit -t 1; ./sort in > fifo \
>> || echo killed via $(env kill -l $(expr $? - 128)))
>
> I ran this 10 times or so on an i7 and couldn't trigger anything. Is
> seq 12 supposed to vary depending on the number of cores?
Hi Chen,
Here's a stand-alone command-line test using the sort in your PATH:
rm -f in fifo
seq 100000 > in
mkfifo fifo
(for i in $(seq 12); do read line; echo $i; sleep .1; done
cat > /dev/null) < fifo &
(ulimit -t 1; sort in > fifo \
|| echo killed via $(env kill -l $(expr $? - 128)))
The 12 x 0.1-second sleeps are to ensure that the busy-waiting
sort will accumulate more than 1.0 seconds of CPU time, and thus
surpass the CPU time limit imposed by "ulimit -t 1".
With more processes, then you may use a number smaller than 12.
Running on a 6-core i7, I see the "killed via XCPU" message
anywhere between the "1" and "4" output lines. E.g.,
1
2
killed via XCPU
$ 3 :
4
5
6
7
8
9
10
11
12
This bug report was last modified 6 years and 202 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.