From: mbligh <mbligh@mbligh.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Ingo Molnar <mingo@elte.hu>, Mike Galbraith <efault@gmx.de>,
linux-kernel@vger.kernel.org
Subject: Re: [Bugme-new] [Bug 7027] New: CD Ripping speeds slow with 2.6.17
Date: Sat, 19 Aug 2006 11:53:38 -0700 [thread overview]
Message-ID: <44E75E32.7020703@mbligh.org> (raw)
In-Reply-To: <20060819111437.a88f71cd.akpm@osdl.org>
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.
next prev parent reply other threads:[~2006-08-19 18:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44E75E32.7020703@mbligh.org \
--to=mbligh@mbligh.org \
--cc=akpm@osdl.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox