On Mon, May 14, 2012 at 03:52:32PM +0100, Mark Hindley wrote:
> The select->can_read() timeout of 0.00001 was the result of lots of
> testing in bug #533830. Reducing the timeout may reduce your throughput
> (which may not bother you ;)!) I am not sure why you see such high CPU
> usage with 0.00001. What hardware is it running on? What is your
> upstream bandwidth/connection?
>
> There are conflicting issues of CPU usage and throughput here, so I
> think I might just make the value configurable as there may not be a
> right value for everybody.
Just thinking about this some more -- I have one instance of apt-cacher
running on an old AMD K6 400 and it never takes more than 10% of the
CPU, so there is something different in your case. I wonder if the
timeout of 0.00001 is just too small for your system. What version of
perl and IO::Select do you have?
strace on the libcurl process on my system shows:
select(8, [0], NULL, NULL, {0, 10}) = 0 (Timeout)
poll([{fd=2, events=POLLIN|POLLPRI}], 1, 0) = 0
clock_gettime(CLOCK_MONOTONIC, {567815, 68106232}) = 0
clock_gettime(CLOCK_MONOTONIC, {567815, 68133052}) = 0
clock_gettime(CLOCK_MONOTONIC, {567815, 68160152}) = 0
clock_gettime(CLOCK_MONOTONIC, {567815, 68186692}) = 0
select(8, [0], NULL, NULL, {0, 10}) = 0 (Timeout)
poll([{fd=2, events=POLLIN|POLLPRI}], 1, 0) = 0
clock_gettime(CLOCK_MONOTONIC, {567815, 69133499}) = 0
clock_gettime(CLOCK_MONOTONIC, {567815, 69160599}) = 0
clock_gettime(CLOCK_MONOTONIC, {567815, 69189654}) = 0
clock_gettime(CLOCK_MONOTONIC, {567815, 69216754}) = 0
select(8, [0], NULL, NULL, {0, 10}) = 0 (Timeout)
The obvious significant difference from your strace are the calls to
clock_gettime. It looks to me as if select() on your system is not
observing the 10us timeout, but I don't know why. Can you test what is
the smallest timeout value that is observed?
Mark
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
