Most recent kernel where this bug did not occur: 2.6.16
Hardware Environment: ASUS K8V mobo, AMD64 2200, 1GB RAM
Software Environment: Gentoo
Problem Description: Ever since 2.6.17 my cd ripping speeds with one particular
CD ripper/encoder (namely the one I wrote) have been slow.
Using git bisect I tracked it down to this patch..
9430d58e34ec3861e1ca72f8e49105b227aad327 is first bad commit
Author: Mike Galbraith <email@example.com>
Date: Wed Mar 22 00:07:33 2006 -0800
[PATCH] sched: remove sleep_avg multiplier
Remove the sleep_avg multiplier. This multiplier was necessary back when
we had 10 seconds of dynamic range in sleep_avg, but now that we only have
one second, it causes that one second to be compressed down to 100ms in
some cases. This is particularly noticeable when compiling a kernel in a
slow NFS mount, and I believe it to be a very likely candidate for other
recently reported network related interactivity problems.
In testing, I can detect no negative impact of this removal.
Signed-off-by: Mike Galbraith <firstname.lastname@example.org>
Acked-by: Ingo Molnar <email@example.com>
Signed-off-by: Andrew Morton <firstname.lastname@example.org>
Signed-off-by: Linus Torvalds <email@example.com>
:040000 040000 28d2d8f53ab7b5dd89e846f2dcc107ce88cb695f 780a13c0f8ba5465db79c668
I'm honestly not sure if my application is doing something it shouldn't or if
this is a legitimate kernel bug. Being totally at a loss I'm filing it here.I
just know that before the above patch I was ripping at about speeds of 9.0x and
now I rip at 1.2x.
Created attachment 8834 [details]
My dmesg output
Hi Ryan, I'm not sure Mike or Ingo will see this bug unless you mail it to them
(Andrew probably will, but he's also pretty busy). Could you also send a mail to
LKML, Cc'ing Mike and Ingo, with this bug # (or a link), to make sure they know
about the issue? We probably don't want the regression to continue into 2.6.18,
or we want to know it's an application bug and an appropriate fix.
Downstream bug http://bugs.gentoo.org/142127
Ryan, if possible, it might help if you could post the source code to your cd
ripper so that other people can attempt to reproduce.
source code for RipOff, the cd ripper that is having the problem here:
The extraction functionality is contained in src/RipOffExtractor.c I am also
the maintainer of this project.
Ok, so after further investigation and playing around with the threads in my
program, I found that the 100% CPU usage is caused by a busy wait. Having the
thread with the busy wait yield has provided a band-aid solution that has
returned my ripping speeds to 9.0x. Looks like a case of a poorly behaving
application affected by a scheduler change to me.
Discussions on the LKML seem to indicate that this is a ripoff bug. Any
objections to me closing this?
Yup, feel free to close it.