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: Re: Does smp_reschedule_interrupt really reschedule?
Date: Sat, 14 May 2005 07:32:29 -0400	[thread overview]
Message-ID: <1116070349.1604.20.camel@localhost.localdomain> (raw)
In-Reply-To: <20050514063741.GA12217@elte.hu>

On Sat, 2005-05-14 at 08:37 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > In finish_task_switch, where is need_resched set?
> 
> why should it be set? It's the final portion of a context-switch, not 
> the initiator of a context-switch. need_resched is usually set by the 
> wakeup code, or by the preemption code.
> 

Sorry, I'm still not seeing it. I'll explain my confusion a little more
detailed now.

Lets say we have a SMP machine with two CPUs.  CPU0 has a RT task
running and CPU1 has a non-RT task.   A RT task wakes up on CPU0 that is
higher priority than the current running RT task on CPU0. Lets add that
this newly woken up RT task has set affinity to only run on CPU0.

So in try_to_wake_up...  Lets assume that the wake up happened on CPU1. 

	if (cpu == this_cpu || unlikely(!cpu_isset(this_cpu, p->cpus_allowed)))
		goto out_set_cpu;

cpu = the task's cpu = CPU0
this_cpu = CPU1

cpu_isset(this_cpu, p->cpus_allowed) returns false so we goto
out_set_cpu.

out_set_cpu:
	new_cpu = wake_idle(new_cpu, p);   <--- new_cpu would still equal cpu.
	if (new_cpu != cpu) {

	} else {
		/*
		 * If a newly woken up RT task cannot preempt the
		 * current (RT) task then try to find another
		 * CPU it can preempt:
		 */
p can preempt current, so this is also false.
		if (rt_task(p) && !TASK_PREEMPTS_CURR(p, rq)) {
			smp_send_reschedule_allbutself();
			rt_overload_wakeup++;
		}
	}


Next we activate the newly woken up RT task.

	activate_task(p, rq, cpu == this_cpu);
	if (!sync || cpu != this_cpu) {
		if (TASK_PREEMPTS_CURR(p, rq))
			resched_task(rq->curr);
	}


So now the newly woken up RT task preempts the other RT task on CPU0.

preempt_schedule is called and then schedule. 

Now the booted RT task should now be transferred to CPU1, since it can
run there, and CPU1 doesn't have a RT task running.

In finish_task_switch, we have:

#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->array && rt_task(prev))) {
		rt_overload_schedule++;
		smp_send_reschedule_allbutself();
	}
#endif


Here's my question, where does CPU1 get need_resched set?  As discussed
earlier, smp_send_reschedule_allbutself doesn't do it.

Thanks,

-- Steve




  reply	other threads:[~2005-05-14 11:32 UTC|newest]

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