Bug 7027
Summary: | CD Ripping speeds slow with 2.6.17 | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Ryan Newberry (brnewber) |
Component: | IDE | Assignee: | Bartlomiej Zolnierkiewicz (bzolnier) |
Status: | REJECTED INVALID | ||
Severity: | normal | CC: | kernel |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.18-rc4 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | My dmesg output |
Description
Ryan Newberry
2006-08-19 10:53:29 UTC
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. |