* Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 [not found] <200608191800.k7JI0ML0015395@fire-2.osdl.org> @ 2006-08-19 18:14 ` Andrew Morton 2006-08-19 18:53 ` mbligh 2006-08-20 8:27 ` Mike Galbraith 0 siblings, 2 replies; 9+ messages in thread From: Andrew Morton @ 2006-08-19 18:14 UTC (permalink / raw) To: Ingo Molnar, Mike Galbraith, Martin Bligh; +Cc: linux-kernel On Sat, 19 Aug 2006 11:00:22 -0700 bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=7027 > > Summary: CD Ripping speeds slow with 2.6.17 > Kernel Version: 2.6.17 > Status: NEW > Severity: normal > Owner: bzolnier@gmail.com > Submitter: brnewber@gmail.com > > > 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. > sched problems... Martin, this might be the source of your `dvdrip' woes? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 2006-08-19 18:14 ` [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 Andrew Morton @ 2006-08-19 18:53 ` mbligh 2006-08-20 8:27 ` Mike Galbraith 1 sibling, 0 replies; 9+ messages in thread From: mbligh @ 2006-08-19 18:53 UTC (permalink / raw) To: Andrew Morton; +Cc: Ingo Molnar, Mike Galbraith, linux-kernel Andrew Morton wrote: > On Sat, 19 Aug 2006 11:00:22 -0700 > bugme-daemon@bugzilla.kernel.org wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=7027 >> >> Summary: CD Ripping speeds slow with 2.6.17 >> Kernel Version: 2.6.17 >> Status: NEW >> Severity: normal >> Owner: bzolnier@gmail.com >> Submitter: brnewber@gmail.com >> >> >> 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. >> > > sched problems... > > Martin, this might be the source of your `dvdrip' woes? > Nope, was an older kernel than that, and oddly doesn't always seem to happen. I'll try to get that box upgraded, and try to reproduce it again. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 2006-08-19 18:14 ` [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 Andrew Morton 2006-08-19 18:53 ` mbligh @ 2006-08-20 8:27 ` Mike Galbraith 2006-08-20 10:03 ` Mike Galbraith 1 sibling, 1 reply; 9+ messages in thread From: Mike Galbraith @ 2006-08-20 8:27 UTC (permalink / raw) To: brnewber; +Cc: Ingo Molnar, Martin Bligh, linux-kernel, Andrew Morton On Sat, 2006-08-19 at 11:14 -0700, Andrew Morton wrote: > On Sat, 19 Aug 2006 11:00:22 -0700 > bugme-daemon@bugzilla.kernel.org wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=7027 > > > > Summary: CD Ripping speeds slow with 2.6.17 > > Kernel Version: 2.6.17 > > Status: NEW > > Severity: normal > > Owner: bzolnier@gmail.com > > Submitter: brnewber@gmail.com > > > > > > 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. It's pretty difficult imagining this patch being responsible for an IO regression. The scheduling advantages for applications which sleep even a little is still absolutely massive. > sched problems... I'm skeptical. Is the source for this application available? I'd like to see this problem. -Mike ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 2006-08-20 8:27 ` Mike Galbraith @ 2006-08-20 10:03 ` Mike Galbraith 2006-08-20 11:11 ` Mike Galbraith 0 siblings, 1 reply; 9+ messages in thread From: Mike Galbraith @ 2006-08-20 10:03 UTC (permalink / raw) To: brnewber; +Cc: Ingo Molnar, Martin Bligh, linux-kernel, Andrew Morton On Sun, 2006-08-20 at 08:27 +0000, Mike Galbraith wrote: > I'm skeptical. Is the source for this application available? I'd like > to see this problem. (never mind. saw your other post, found source) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 2006-08-20 10:03 ` Mike Galbraith @ 2006-08-20 11:11 ` Mike Galbraith 2006-08-20 13:48 ` Jan Engelhardt 0 siblings, 1 reply; 9+ messages in thread From: Mike Galbraith @ 2006-08-20 11:11 UTC (permalink / raw) To: brnewber; +Cc: Ingo Molnar, Martin Bligh, linux-kernel, Andrew Morton On Sun, 2006-08-20 at 10:03 +0000, Mike Galbraith wrote: > On Sun, 2006-08-20 at 08:27 +0000, Mike Galbraith wrote: > > > I'm skeptical. Is the source for this application available? I'd like > > to see this problem. > > (never mind. saw your other post, found source) Hm. I can't get better than 1.4x rip speed out of it with a stock SuSE 10.1 kernel (2.6.16). It's also using truckloads of cpu, whereas the CD rippers that came with this distro use a percent or two. -Mike ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 2006-08-20 11:11 ` Mike Galbraith @ 2006-08-20 13:48 ` Jan Engelhardt 2006-08-20 17:28 ` Ryan Newberry 0 siblings, 1 reply; 9+ messages in thread From: Jan Engelhardt @ 2006-08-20 13:48 UTC (permalink / raw) To: Mike Galbraith Cc: brnewber, Ingo Molnar, Martin Bligh, linux-kernel, Andrew Morton >> > I'm skeptical. Is the source for this application available? I'd like >> > to see this problem. >> >> (never mind. saw your other post, found source) > >Hm. I can't get better than 1.4x rip speed out of it with a stock SuSE >10.1 kernel (2.6.16). It's also using truckloads of cpu, whereas the CD >rippers that came with this distro use a percent or two. What command did you use to rip? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 2006-08-20 13:48 ` Jan Engelhardt @ 2006-08-20 17:28 ` Ryan Newberry 2006-08-20 22:56 ` Mike Galbraith 2006-08-22 12:02 ` Jan Engelhardt 0 siblings, 2 replies; 9+ messages in thread From: Ryan Newberry @ 2006-08-20 17:28 UTC (permalink / raw) To: Jan Engelhardt Cc: Mike Galbraith, Ingo Molnar, Martin Bligh, linux-kernel, Andrew Morton Jan Engelhardt wrote: >>>> I'm skeptical. Is the source for this application available? I'd like >>>> to see this problem. >>>> >>> (never mind. saw your other post, found source) >>> >> Hm. I can't get better than 1.4x rip speed out of it with a stock SuSE >> 10.1 kernel (2.6.16). It's also using truckloads of cpu, whereas the CD >> rippers that came with this distro use a percent or two. >> > > What command did you use to rip? > > > > Jan Engelhardt > The ripper he's using is ripoff I assume (source code here: http://prdownloads.sourceforge.net/ripoffc/ripoff-0.8.tar.gz?download extraction functionality contained in src/RipOffExtractor.c) . It uses libparanoia to do its job, like the cdparanoia command. On my system, ripoff has high CPU usage with a 2.6.16 kernel as well, but it reports a 9.0x rate on average. Could the fact that it has such high CPU usage be a possible reason I am experiencing a slower ripping speed (1.2x) when the patch that was git bisected is applied? -- Ryan Newberry http://ripoffc.sourceforge.net "All mankind is divided into three classes: those that are immovable, those that are movable, and those that move." - Benjamin Franklin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 2006-08-20 17:28 ` Ryan Newberry @ 2006-08-20 22:56 ` Mike Galbraith 2006-08-22 12:02 ` Jan Engelhardt 1 sibling, 0 replies; 9+ messages in thread From: Mike Galbraith @ 2006-08-20 22:56 UTC (permalink / raw) To: Ryan Newberry Cc: Jan Engelhardt, Ingo Molnar, Martin Bligh, linux-kernel, Andrew Morton On Sun, 2006-08-20 at 13:28 -0400, Ryan Newberry wrote: > Jan Engelhardt wrote: > >>>> I'm skeptical. Is the source for this application available? I'd like > >>>> to see this problem. > >>>> > >>> (never mind. saw your other post, found source) > >>> > >> Hm. I can't get better than 1.4x rip speed out of it with a stock SuSE > >> 10.1 kernel (2.6.16). It's also using truckloads of cpu, whereas the CD > >> rippers that came with this distro use a percent or two. > >> > > > > What command did you use to rip? > > > > > > > > Jan Engelhardt > > > The ripper he's using is ripoff I assume (source code here: > http://prdownloads.sourceforge.net/ripoffc/ripoff-0.8.tar.gz?download > extraction functionality contained in src/RipOffExtractor.c) . It uses > libparanoia to do its job, like the cdparanoia command. On my system, > ripoff has high CPU usage with a 2.6.16 kernel as well, but it reports a > 9.0x rate on average. Watching the .16 kernel, it boosts to interactive status frequently, but even with this mega-boost, it uses so much cpu that it repeatedly falls into the expire (unbounded latency) category. At this point, I think this app has problems. > Could the fact that it has such high CPU usage be a possible reason I am > experiencing a slower ripping speed (1.2x) when the patch that was git > bisected is applied? Short answer, with a lot of interpolation, yes. -Mike ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 2006-08-20 17:28 ` Ryan Newberry 2006-08-20 22:56 ` Mike Galbraith @ 2006-08-22 12:02 ` Jan Engelhardt 1 sibling, 0 replies; 9+ messages in thread From: Jan Engelhardt @ 2006-08-22 12:02 UTC (permalink / raw) To: Ryan Newberry Cc: Mike Galbraith, Ingo Molnar, Martin Bligh, linux-kernel, Andrew Morton >> > rippers that came with this distro use a percent or two. >> >> What command did you use to rip? >> > The ripper he's using is ripoff I assume (source code here: I would suggest trying another one, possibly not based on cdparanoia. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-08-22 12:06 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200608191800.k7JI0ML0015395@fire-2.osdl.org>
2006-08-19 18:14 ` [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17 Andrew Morton
2006-08-19 18:53 ` mbligh
2006-08-20 8:27 ` Mike Galbraith
2006-08-20 10:03 ` Mike Galbraith
2006-08-20 11:11 ` Mike Galbraith
2006-08-20 13:48 ` Jan Engelhardt
2006-08-20 17:28 ` Ryan Newberry
2006-08-20 22:56 ` Mike Galbraith
2006-08-22 12:02 ` Jan Engelhardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox