Most recent kernel where this bug did not occur: 2.6.16 Distribution: Gentoo 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 commit 9430d58e34ec3861e1ca72f8e49105b227aad327 Author: Mike Galbraith <efault@gmx.de> 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 <efault@gmx.de> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> :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. Thanks, Nish
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: http://prdownloads.sourceforge.net/ripoffc/ripoff-0.8.tar.gz?download 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.