public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@keyaccess.nl>
To: Lee Revell <rlrevell@joe-job.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Mike Galbraith <efault@gmx.de>, Ingo Molnar <mingo@elte.hu>,
	Con Kolivas <kernel@kolivas.org>
Subject: Re: 2.6.17-rc2+ regression -- audio skipping
Date: Mon, 22 May 2006 02:10:10 +0200	[thread overview]
Message-ID: <44710162.3070406@keyaccess.nl> (raw)
In-Reply-To: <1148247047.20472.78.camel@mindpipe>

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

Lee Revell wrote:

> On Sun, 2006-05-21 at 22:24 +0200, Rene Herman wrote:

>> 2.6.17-rc2 (and 3 and 4) make my audio skip. Audio player is ogg123 
>> running in an xterm. Browsing heavy sites (say, eBay) with Firefox 
>> 1.5.0.3 gets me audio underruns quickly. This does not happen on 
>> 2.6.17-rc1 and earlier (I just tested extensively; quite impossible to 
>> generate underruns on -rc1, quickly on -rc2 and later).
>>
>> It's not ALSA; reverted */sound/* from the rc1-rc2 interdiff. It's also 
>> not cfq-iosched.c. Any likely culprits in there? (I'm not a GIT user).
>>
> 
> I would suspect the scheduler interactivity patches.  Please confirm
> this by running ogg123 at nice -20 - do the underruns persist?

They do persist. Thanks for the hint though -- "sched: fix interactive 
task starvation" is the culprit:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5ce74abe788a26698876e66b9c9ce7e7acc25413

Added author and acked-by's to the CC. Mike, this patch is no good for 
me. Audio underruns galore, with only ogg123 and firefox (browsing the 
GIT tree online is also a nice trigger by the way).

If I back it out, everything is fine for me again. Back-out attached as 
a patch against -rc4. This also backs out your follow-up "don't awaken 
RT tasks on expired array" as it was dependant:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8a5bc075b8d8cf7a87b3f08fad2fba0f5d13295e

While looking at the patch I noticed there was +1 difference in the 
"limit" value between the macro and the static inline version of 
expired_starving() so I experimented with adding that back but that 
wasn't it unfortunately.

I can test patches (preferably versus -rc4) although possibly not quickly.

Rene.


[-- Attachment #2: unfix_interactive_task_starvation.diff --]
[-- Type: text/plain, Size: 3055 bytes --]

Index: local/kernel/sched.c
===================================================================
--- local.orig/kernel/sched.c	2006-05-08 20:47:06.000000000 +0200
+++ local/kernel/sched.c	2006-05-22 01:03:12.000000000 +0200
@@ -665,55 +665,13 @@ static int effective_prio(task_t *p)
 }
 
 /*
- * We place interactive tasks back into the active array, if possible.
- *
- * To guarantee that this does not starve expired tasks we ignore the
- * interactivity of a task if the first expired task had to wait more
- * than a 'reasonable' amount of time. This deadline timeout is
- * load-dependent, as the frequency of array switched decreases with
- * increasing number of running tasks. We also ignore the interactivity
- * if a better static_prio task has expired, and switch periodically
- * regardless, to ensure that highly interactive tasks do not starve
- * the less fortunate for unreasonably long periods.
- */
-static inline int expired_starving(runqueue_t *rq)
-{
-	int limit;
-
-	/*
-	 * Arrays were recently switched, all is well
-	 */
-	if (!rq->expired_timestamp)
-		return 0;
-
-	limit = STARVATION_LIMIT * rq->nr_running;
-
-	/*
-	 * It's time to switch arrays
-	 */
-	if (jiffies - rq->expired_timestamp >= limit)
-		return 1;
-
-	/*
-	 * There's a better selection in the expired array
-	 */
-	if (rq->curr->static_prio > rq->best_expired_prio)
-		return 1;
-
-	/*
-	 * All is well
-	 */
-	return 0;
-}
-
-/*
  * __activate_task - move a task to the runqueue.
  */
 static void __activate_task(task_t *p, runqueue_t *rq)
 {
 	prio_array_t *target = rq->active;
 
-	if (unlikely(batch_task(p) || (expired_starving(rq) && !rt_task(p))))
+	if (batch_task(p))
 		target = rq->expired;
 	enqueue_task(p, target);
 	rq->nr_running++;
@@ -2532,6 +2490,22 @@ unsigned long long current_sched_time(co
 }
 
 /*
+ * We place interactive tasks back into the active array, if possible.
+ *
+ * To guarantee that this does not starve expired tasks we ignore the
+ * interactivity of a task if the first expired task had to wait more
+ * than a 'reasonable' amount of time. This deadline timeout is
+ * load-dependent, as the frequency of array switched decreases with
+ * increasing number of running tasks. We also ignore the interactivity
+ * if a better static_prio task has expired:
+ */
+#define EXPIRED_STARVING(rq) \
+	((STARVATION_LIMIT && ((rq)->expired_timestamp && \
+		(jiffies - (rq)->expired_timestamp >= \
+			STARVATION_LIMIT * ((rq)->nr_running) + 1))) || \
+			((rq)->curr->static_prio > (rq)->best_expired_prio))
+
+/*
  * Account user cpu time to a process.
  * @p: the process that the cpu time gets accounted to
  * @hardirq_offset: the offset to subtract from hardirq_count()
@@ -2666,7 +2640,7 @@ void scheduler_tick(void)
 
 		if (!rq->expired_timestamp)
 			rq->expired_timestamp = jiffies;
-		if (!TASK_INTERACTIVE(p) || expired_starving(rq)) {
+		if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) {
 			enqueue_task(p, rq->expired);
 			if (p->static_prio < rq->best_expired_prio)
 				rq->best_expired_prio = p->static_prio;

  reply	other threads:[~2006-05-22  0:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-21 20:24 2.6.17-rc2+ regression -- audio skipping Rene Herman
2006-05-21 21:30 ` Lee Revell
2006-05-22  0:10   ` Rene Herman [this message]
2006-05-22  0:17     ` Rene Herman
2006-05-22  0:33     ` Con Kolivas
2006-05-22  2:14       ` Mike Galbraith
2006-05-22  2:43         ` Con Kolivas
2006-05-22  3:10           ` Mike Galbraith
2006-05-22  3:30             ` Peter Williams
2006-05-22  4:53               ` Mike Galbraith
2006-05-22  5:38                 ` Peter Williams
2006-05-22  6:00                   ` Mike Galbraith
2006-05-22  6:34                     ` Peter Williams
2006-05-23  5:22                       ` Peter Williams
2006-05-22  3:26           ` Peter Williams
2006-05-22 18:22         ` Rene Herman

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=44710162.3070406@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=efault@gmx.de \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rlrevell@joe-job.com \
    --cc=torvalds@osdl.org \
    /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