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>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] sched_rt_rq_enqueue() resched idle
Date: Wed, 27 Aug 2008 15:19:03 +0200 [thread overview]
Message-ID: <1219843143.6462.86.camel@twins> (raw)
In-Reply-To: <48B55122.6080807@ccur.com>
Ingo, please apply.
---
Subject: sched: sched_rt_rq_enqueue() resched idle
From: John Blackwood <john.blackwood@ccur.com>
Date: Tue, 26 Aug 2008 15:09:43 -0400
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.
Signed-off-by: John Blackwood <john.blackwood@ccur.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/sched_rt.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/kernel/sched_rt.c
===================================================================
--- linux-2.6.orig/kernel/sched_rt.c
+++ linux-2.6/kernel/sched_rt.c
@@ -199,6 +199,8 @@ static inline struct rt_rq *group_rt_rq(
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)
next prev parent reply other threads:[~2008-08-27 13:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 13:05 [PATCH] sched_rt_rq_enqueue() resched idle John Blackwood
2008-08-27 13:19 ` Peter Zijlstra [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-08-26 19:09 John Blackwood
2008-08-27 8:03 ` 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=1219843143.6462.86.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=john.blackwood@ccur.com \
--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 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.