All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: John Blackwood <john.blackwood@ccur.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH] sched_rt_rq_enqueue() resched idle
Date: Wed, 27 Aug 2008 10:03:37 +0200	[thread overview]
Message-ID: <1219824217.6462.44.camel@twins> (raw)
In-Reply-To: <48B454F7.5060106@ccur.com>

On Tue, 2008-08-26 at 15:09 -0400, John Blackwood wrote:
> Hi Peter,
> 
> When sysctl_sched_rt_runtime is set to something other than -1 and the
> CONFIG_RT_GROUP_SCHED kernel parameter is NOT enabled, we get into a state
> where we see one or more CPUs idling forvever even though there are
> real-time
> tasks in their rt runqueue that are able to run (no longer throttled).
> 
> The sequence is:
> 
> - A real-time task is running when the timer sets the rt runqueue
>     to throttled, and the rt task is resched_task()ed and switched
>     out, and idle is switched in since there are no non-rt tasks to
>     run on that cpu.
> 
> - Eventually the do_sched_rt_period_timer() runs and un-throttles
>     the rt runqueue, but we just exit the timer interrupt and go back
>     to executing the idle task in the idle loop forever.
> 
> If we change the sched_rt_rq_enqueue() routine to use some of the code
> from the CONFIG_RT_GROUP_SCHED enabled version of this same routine and
> resched_task() the currently executing task (idle in our case) if it is
> a lower priority task than the higher rt task in the now un-throttled
> runqueue, the problem is no longer observed.

Very good spotting, Thanks!

However I think the patch isn't quite good, as highest_prio is only
available on SMP || RT_GROUP_SCHED.

Furthermore, on !RT_GROUP_SCHED any RT task will be higher than current,
so we can do the below, do you agree?

---
diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index 94daace..f672aee 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -199,6 +199,8 @@ static inline struct rt_rq *group_rt_rq(struct sched_rt_entity *rt_se)
 
 static inline void sched_rt_rq_enqueue(struct rt_rq *rt_rq)
 {
+	if (rt_rq->rt_nr_running)
+		resched_task(rq_of_rt_rq(rt_rq)->curr);
 }
 
 static inline void sched_rt_rq_dequeue(struct rt_rq *rt_rq)



  reply	other threads:[~2008-08-27  8:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-26 19:09 [PATCH] sched_rt_rq_enqueue() resched idle John Blackwood
2008-08-27  8:03 ` Peter Zijlstra [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-08-27 13:05 John Blackwood
2008-08-27 13:19 ` Peter Zijlstra

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=1219824217.6462.44.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=efault@gmx.de \
    --cc=john.blackwood@ccur.com \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.