All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Does smp_reschedule_interrupt really reschedule?
Date: Fri, 13 May 2005 14:18:19 -0400	[thread overview]
Message-ID: <1116008299.4728.19.camel@localhost.localdomain> (raw)

I'm working mostly with Ingo's RT patched kernel, but this may also be a
problem with the vanilla kernel.

Sending out a smp_send_reschedule which causes the
smp_reschedule_interrupt to go off on each CPU. (In Ingo's I was more
concerned with the smp_send_reschedule_allbutself).  In
arch/i386/kernel/smp.c there's the following code:

/*
 * Reschedule call back. Nothing to do,
 * all the work is done automatically when
 * we return from the interrupt.
 */
fastcall void smp_reschedule_interrupt(struct pt_regs *regs)
{
        ack_APIC_irq();
}



As the comment says, do nothing since all the work is automatically done
at the return from interrupt. But is it?  Doesn't the need_resched need
to be set?  Here's what I'm seeing with Ingo's kernel.  I capture the
time in sched.c when the smp_send_reschedule_allbutself is called, and
also a capture of the time when the schedule actually takes place.  I'm
finding differences up to 2 tenths of a second.  That's TENTHS!  I added
the following patch:

--- arch/i386/kernel/smp.c	(revision 181)
+++ arch/i386/kernel/smp.c	(working copy)
@@ -593,6 +593,7 @@
 {
 	trace_special(regs->eip, 0, 0);
 	ack_APIC_irq();
+	set_tsk_need_resched(current);
 }
 
 fastcall void smp_call_function_interrupt(struct pt_regs *regs)


(OK the trace_special is from Ingo's patch, but that's what I was
working with)

Now the largest latency between the call smp_send_reschedule and
schedule being called on another CPU is now 200 micro seconds, which is
much more reasonable.  But it also shows that a schedule is not taking
place without it.

Now, is there more logic that I'm missing to determine if the schedule
is not needed.  With Ingo's patch, he sends this when two RT tasks are
scheduled on the same CPU and one should migrate.  But the time this
takes varies tremendously.

Thanks,


-- Steve


Here's the patch for 2.6.11.6, just in case this is an issue. You just
need to delete the one for Ingo's. And Ingo would need to delete this.
Then again, the above is for a -p0 and this is -p1.

--- a/arch/i386/kernel/smp.c.orig	2005-05-13 14:06:54.000000000 -0400
+++ a/arch/i386/kernel/smp.c	2005-05-13 14:07:28.000000000 -0400
@@ -582,6 +582,7 @@
 fastcall void smp_reschedule_interrupt(struct pt_regs *regs)
 {
 	ack_APIC_irq();
+	set_tsk_need_resched(current);
 }
 
 fastcall void smp_call_function_interrupt(struct pt_regs *regs)



             reply	other threads:[~2005-05-13 18:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13 18:18 Steven Rostedt [this message]
2005-05-13 18:26 ` Does smp_reschedule_interrupt really reschedule? Ingo Molnar
2005-05-13 18:51   ` Steven Rostedt
2005-05-14  6:37     ` Ingo Molnar
2005-05-14 11:32       ` Steven Rostedt
2005-05-14 14:27         ` Ingo Molnar

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=1116008299.4728.19.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=akpm@osdl.org \
    --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.