Bug 7027 - CD Ripping speeds slow with 2.6.17
CD Ripping speeds slow with 2.6.17
Status: REJECTED INVALID
Product: IO/Storage
Classification: Unclassified
Component: IDE
i386 Linux
: P2 normal
Assigned To: Bartlomiej Zolnierkiewicz
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-19 10:53 UTC by Ryan Newberry
Modified: 2006-08-28 07:15 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.18-rc4
Tree: Mainline
Regression: ---


Attachments
My dmesg output (13.04 KB, text/plain)
2006-08-19 10:54 UTC, Ryan Newberry
Details

Description Ryan Newberry 2006-08-19 10:53:29 UTC
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.
Comment 1 Ryan Newberry 2006-08-19 10:54:24 UTC
Created attachment 8834 [details]
My dmesg output
Comment 2 Nishanth Aravamudan 2006-08-19 11:27:25 UTC
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
Comment 3 Daniel Drake 2006-08-20 06:51:16 UTC
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.
Comment 4 Ryan Newberry 2006-08-20 11:45:43 UTC
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.
Comment 5 Ryan Newberry 2006-08-20 13:16:25 UTC
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.
Comment 6 Daniel Drake 2006-08-27 15:28:28 UTC
Discussions on the LKML seem to indicate that this is a ripoff bug. Any
objections to me closing this?
Comment 7 Ryan Newberry 2006-08-28 04:52:59 UTC
Yup, feel free to close it.

Note You need to log in before you can comment on or make changes to this bug.