Re: [PATCH RT] fix rt-task scheduling issue
On Mon, Oct 08, 2007 at 10:46:21PM -0400, Steven Rostedt wrote:
> Mike,
>
> Can you attach your Signed-off-by to this patch, please.
>
>
> On Fri, Oct 05, 2007 at 07:15:48PM -0700, Mike Kravetz wrote:
> > Hi Ingo,
> >
> > After applying the fix to try_to_wake_up() I was still seeing some large
> > latencies for realtime tasks. Some debug code pointed out two additional
> > causes of these latencies. I have put fixes into my 'old' kernel and the
> > scheduler related latencies have gone away. I'm pretty confident that
> > one of these bugs still exist in the latest RT patch set. Not so sure
> > about the other. But, I wanted to describe in detail so that you could
> > address in the latest version of the code if applicable.
> >
> > finish_task_switch() contains the following code:
> >
> > #if defined(CONFIG_PREEMPT_RT) && defined(CONFIG_SMP)
> > /*
> > * If we pushed an RT task off the runqueue,
> > * then kick other CPUs, they might run it:
> > */
> > if (unlikely(rt_task(current) && prev->se.on_rq && rt_task(prev))) {
> > schedstat_inc(rq, rto_schedule);
> > smp_send_reschedule_allbutself_cpumask(current->cpus_allowed);
> > }
> > #endif
> >
> > My debug code found instances where more than one realtime task got
> > put on the runqueue before the __schedule() was invoked. So, current
> > would be a realtime task, but prev was not realtime. And, there was
> > another (lesser priority, or last in) realtime task on the queue. I
> > believe that in this case we would still want to send the IPIs. In my
> > kernel I changed the test to be:
> >
> > if (unlikely(rt_task(current) && rq->rt_nr_running > 1)) {
> >
> > After this change, I definitely saw some long latencies go away.
OK, not really a patch but
Signed-off-by: Mike Kravetz <[EMAIL PROTECTED]>
--
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT] fix rt-task scheduling issue
On Mon, Oct 08, 2007 at 10:46:21PM -0400, Steven Rostedt wrote:
Mike,
Can you attach your Signed-off-by to this patch, please.
On Fri, Oct 05, 2007 at 07:15:48PM -0700, Mike Kravetz wrote:
Hi Ingo,
After applying the fix to try_to_wake_up() I was still seeing some large
latencies for realtime tasks. Some debug code pointed out two additional
causes of these latencies. I have put fixes into my 'old' kernel and the
scheduler related latencies have gone away. I'm pretty confident that
one of these bugs still exist in the latest RT patch set. Not so sure
about the other. But, I wanted to describe in detail so that you could
address in the latest version of the code if applicable.
finish_task_switch() contains the following code:
#if defined(CONFIG_PREEMPT_RT) defined(CONFIG_SMP)
/*
* If we pushed an RT task off the runqueue,
* then kick other CPUs, they might run it:
*/
if (unlikely(rt_task(current) prev-se.on_rq rt_task(prev))) {
schedstat_inc(rq, rto_schedule);
smp_send_reschedule_allbutself_cpumask(current-cpus_allowed);
}
#endif
My debug code found instances where more than one realtime task got
put on the runqueue before the __schedule() was invoked. So, current
would be a realtime task, but prev was not realtime. And, there was
another (lesser priority, or last in) realtime task on the queue. I
believe that in this case we would still want to send the IPIs. In my
kernel I changed the test to be:
if (unlikely(rt_task(current) rq-rt_nr_running 1)) {
After this change, I definitely saw some long latencies go away.
OK, not really a patch but
Signed-off-by: Mike Kravetz [EMAIL PROTECTED]
--
Mike
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT] fix rt-task scheduling issue
Hi Guys,
Nice find! Comment inline..
(adding linux-rt-users)
for reference to
http://lkml.org/lkml/2007/10/8/252
On Mon, 2007-10-08 at 22:46 -0400, Steven Rostedt wrote:
> Index: linux-2.6.23-rc9-rt2/kernel/sched.c
> ===
> --- linux-2.6.23-rc9-rt2.orig/kernel/sched.c
> +++ linux-2.6.23-rc9-rt2/kernel/sched.c
> @@ -2207,7 +2207,7 @@ static inline void finish_task_switch(st
>* If we pushed an RT task off the runqueue,
>* then kick other CPUs, they might run it:
>*/
> - if (unlikely(rt_task(current) && prev->se.on_rq && rt_task(prev))) {
> + if (unlikely(rt_task(current) && rq->rt_nr_running > 1)) {
> schedstat_inc(rq, rto_schedule);
> smp_send_reschedule_allbutself_cpumask(current->cpus_allowed);
the current->cpus_allowed I think probably should have been
"prev->cpus_allowed" in the original code? However, in light of the new
findings with this bug Mike found, this should probably be sent to
allbutself() without the mask since you don't know what could have been
queued behind you.
Unless I am missing something?
Regards,
-Greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT] fix rt-task scheduling issue
Hi Guys,
Nice find! Comment inline..
(adding linux-rt-users)
for reference to
http://lkml.org/lkml/2007/10/8/252
On Mon, 2007-10-08 at 22:46 -0400, Steven Rostedt wrote:
Index: linux-2.6.23-rc9-rt2/kernel/sched.c
===
--- linux-2.6.23-rc9-rt2.orig/kernel/sched.c
+++ linux-2.6.23-rc9-rt2/kernel/sched.c
@@ -2207,7 +2207,7 @@ static inline void finish_task_switch(st
* If we pushed an RT task off the runqueue,
* then kick other CPUs, they might run it:
*/
- if (unlikely(rt_task(current) prev-se.on_rq rt_task(prev))) {
+ if (unlikely(rt_task(current) rq-rt_nr_running 1)) {
schedstat_inc(rq, rto_schedule);
smp_send_reschedule_allbutself_cpumask(current-cpus_allowed);
the current-cpus_allowed I think probably should have been
prev-cpus_allowed in the original code? However, in light of the new
findings with this bug Mike found, this should probably be sent to
allbutself() without the mask since you don't know what could have been
queued behind you.
Unless I am missing something?
Regards,
-Greg
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
