[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <82e4877d0805020410u78c6f03fr8e8e53d5a19f6846@mail.gmail.com>
Date: Fri, 2 May 2008 07:10:37 -0400
From: "Parag Warudkar" <parag.warudkar@...il.com>
To: "Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Cc: "Ingo Molnar" <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
"Frans Pop" <elendil@...net.nl>, "Mike Galbraith" <efault@....de>
Subject: Re: Horrendous Audio Stutter - current git
On Fri, May 2, 2008 at 4:34 AM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> On Thu, 2008-05-01 at 20:14 -0400, Parag Warudkar wrote:
>
> Parag, would you also test with !NEW_FAIR_SLEEPERS to see if that solves
> your problem?
>
> The easiest way to disable it is (assumes you have debugfs mounted
> at /debug):
>
> # echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features
Seems to make it stutter a little less - but still not usable.
>
> You can also disable NORMALIZED_SLEEPER that way (of course you would
> first have to enable NEW_FAIR_SLEEPERS again):
>
> # echo NO_NORMALIZED_SLEEPER > /debug/sched_features
>
No significant difference from NO_NEW_FAIR_SLEEPERS that I can tell.
> So by default we have both enabled; could you report if either
>
> NO_NEW_FAIR_SLEEPERS
>
> NEW_FAIR_SLEEPERS + NO_NORMALIZED_SLEEPERS
>
> works for you?
I would say no - the audio still is unusable - slightly better with
NO_NEW_FAIR_SLEEPERS, no difference with the other.
But per Mike's suggestion if I disable CONFIG_GROUP_SCHED ,
CONFIG_FAIR_GROUP_SCHED and CONFIG_USER_SCHED, even with
NEW_FAIR_SLEEPERS audio is good again, which does not change with
NO_NEW_FAIR_SLEEPERS. (No skips for long time under -j8 - still skips
a _very_ tiny bit - noticeable if I listen too carefully - but we can
ignore that for the time being.)
Mike - the GROUP_SCHED stuff is set to y in the Ubuntu kernel and I
have no audio skips - may be a regression introduced after 2.6.24?
But why is the GROUP_SCHED stuff default y if it so unusable?
>
> Also, could you apply this patch, and report the bonus_max value for
> your music player under all three scenarios?
>
I see Frans already reported that and there was some conclusion - let
me know if more data will help.
Thanks!
Parag
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists