All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <kravetz@us.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RT] fix rt-task scheduling issue
Date: Tue, 9 Oct 2007 11:51:08 -0700	[thread overview]
Message-ID: <20071009185108.GA14419@monkey.ibm.com> (raw)
In-Reply-To: <20071009024621.GA12915@goodmis.org>

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 <kravetz@us.ibm.com>

-- 
Mike

      parent reply	other threads:[~2007-10-09 18:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-06  2:15 -rt more realtime scheduling issues Mike Kravetz
2007-10-08 18:45 ` Mike Kravetz
2007-10-09  3:04   ` Steven Rostedt
2007-10-09  8:16     ` Peter Zijlstra
2007-10-09 18:49     ` Mike Kravetz
2007-10-10 11:50       ` Steven Rostedt
2007-10-11  2:37         ` Mike Kravetz
2007-10-09  2:46 ` [PATCH RT] fix rt-task scheduling issue Steven Rostedt
2007-10-09  4:18   ` Gregory Haskins
2007-10-09 18:51   ` Mike Kravetz [this message]

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=20071009185108.GA14419@monkey.ibm.com \
    --to=kravetz@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.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.