While testing a shell script with sbase and ubase, I ran into a problem
where dd would chew up my CPU whenever it read from a slow file. I
noticed this when running "dd" in a pipeline with "/dev/random" while my
system was low on entropy. Here are the timing outputs from ubase's dd
compared to GNU coreutils running on the same system:
# Suckless Unportable Base:
$ time (ubase-box dd if=/dev/random bs=1 count=16 &>/dev/null)
real0m12.673s
user0m2.992s
sys 0m9.656s
# GNU Core Utilities:
$ time (coreutils --coreutils-prog=dd if=/dev/random bs=1 count=16
&>/dev/null)
real0m16.987s
user0m0.000s
sys 0m0.004s
The amount of sys time spent by ubase's dd is always a lot higher than
coreutil's even when the wall-clock time of the runs is comparable. I
haven't spent a lot of time looking into this yet, so I don't have a
patch prepared, but glancing at strace showed rapid invocations of
select(2) which often alternated between succeeding and ENOSYS:
$ strace -o '!uniq -c >&2' ubase-box dd if=/dev/random bs=1 count=16
>/dev/null
[...]
1 splice(4, NULL, 1, NULL, 1, SPLICE_F_MORE) = 1
1 select(4, [3], [1], NULL, NULL) = 2 (in [3], out [1])
1 splice(3, NULL, 5, NULL, 1, SPLICE_F_MORE) = 1
1 splice(4, NULL, 1, NULL, 1, SPLICE_F_MORE) = 1
5074 select(4, [3], [1], NULL, NULL) = 1 (out [1])
152992 select(4, [], [1], NULL, NULL) = -1 ENOSYS (Function
not implemented)
1 select(4, [3], [1], NULL, NULL) = 1 (out [1])
1 select(4, [3], [1], NULL, NULL) = -1 ENOSYS (Function
not implemented)
34335 select(4, [], [1], NULL, NULL) = -1 ENOSYS (Function
not implemented)
34778 select(4, [3], [1], NULL, NULL) = 1 (out [1])
1 select(4, [3], [1], NULL, NULL) = 2 (in [3], out [1])
1 splice(3, NULL, 5, NULL, 1, SPLICE_F_MORE) = 1
1 splice(4, NULL, 1, NULL, 1, SPLICE_F_MORE) = 1
1 select(4, [3], [1], NULL, NULL) = 2 (in [3], out [1])
[...]
Eric
