From: Ingo Molnar <mingo@elte.hu>
To: Darren Hart <dvhltc@us.ibm.com>
Cc: linux-kerneL@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH -rt] Priority preemption latency
Date: Sun, 11 Jun 2006 07:58:28 +0200 [thread overview]
Message-ID: <20060611055828.GA9452@elte.hu> (raw)
In-Reply-To: <200606102249.26063.dvhltc@us.ibm.com>
* Darren Hart <dvhltc@us.ibm.com> wrote:
> Thanks for the updated patch! It wouldn't quite build (proc_misc.c
> still referenced the old rt_overload_* variables, fixup patch attached
> removing those print statements). [...]
doh, forgot to send those changes ...
> [...] I have it running on a 4 way opteron box running prio-preempt
> in a timed while loop, exiting only on failure. It's been running
> fine for several minutes - usually fails in under a mintue. We'll see
> how it's doing in the morning :-)
meanwhile i've released -rt3 with the fix (and the procfs change)
included.
i slept on it meanwhile, and i think the safest would be to also do the
attached patch ontop of -rt3. This makes the 'kick other CPUs' logic
totally unconditional - so whatever happens the wakeup code will notice
if an RT task is in trouble finding the right CPU. Under -rt3 we'd only
run into this branch if we stayed on the same CPU - but there can be
cases when we have your scenario even in precisely such a case. It's
rare but possible.
Ingo
Index: linux-rt.q/kernel/sched.c
===================================================================
--- linux-rt.q.orig/kernel/sched.c
+++ linux-rt.q/kernel/sched.c
@@ -1588,38 +1588,37 @@ out_set_cpu:
this_cpu = smp_processor_id();
cpu = task_cpu(p);
- } else {
+ }
+ /*
+ * If a newly woken up RT task cannot preempt the
+ * current (RT) task (on a target runqueue) then try
+ * to find another CPU it can preempt:
+ */
+ if (rt_task(p) && !TASK_PREEMPTS_CURR(p, rq)) {
+ this_rq = cpu_rq(this_cpu);
/*
- * If a newly woken up RT task cannot preempt the
- * current (RT) task (on a target runqueue) then try
- * to find another CPU it can preempt:
+ * Special-case: the task on this CPU can be
+ * preempted. In that case there's no need to
+ * trigger reschedules on other CPUs, we can
+ * mark the current task for reschedule.
+ *
+ * (Note that it's safe to access this_rq without
+ * extra locking in this particular case, because
+ * we are on the current CPU.)
*/
- if (rt_task(p) && !TASK_PREEMPTS_CURR(p, rq)) {
- this_rq = cpu_rq(this_cpu);
+ if (TASK_PREEMPTS_CURR(p, this_rq))
+ set_tsk_need_resched(this_rq->curr);
+ else
/*
- * Special-case: the task on this CPU can be
- * preempted. In that case there's no need to
- * trigger reschedules on other CPUs, we can
- * mark the current task for reschedule.
- *
- * (Note that it's safe to access this_rq without
- * extra locking in this particular case, because
- * we are on the current CPU.)
+ * Neither the intended target runqueue
+ * nor the current CPU can take this task.
+ * Trigger a reschedule on all other CPUs
+ * nevertheless, maybe one of them can take
+ * this task:
*/
- if (TASK_PREEMPTS_CURR(p, this_rq))
- set_tsk_need_resched(this_rq->curr);
- else
- /*
- * Neither the intended target runqueue
- * nor the current CPU can take this task.
- * Trigger a reschedule on all other CPUs
- * nevertheless, maybe one of them can take
- * this task:
- */
- smp_send_reschedule_allbutself();
+ smp_send_reschedule_allbutself();
- schedstat_inc(this_rq, rto_wakeup);
- }
+ schedstat_inc(this_rq, rto_wakeup);
}
out_activate:
next prev parent reply other threads:[~2006-06-11 5:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-10 0:01 [RFC PATCH -rt] Priority preemption latency Darren Hart
2006-06-10 6:48 ` Ingo Molnar
2006-06-10 7:21 ` Ingo Molnar
2006-06-11 5:49 ` Darren Hart
2006-06-11 5:58 ` Ingo Molnar [this message]
2006-06-11 6:37 ` Ingo Molnar
2006-06-11 6:24 ` Darren Hart
2006-06-11 7:36 ` Ingo Molnar
2006-06-12 15:38 ` Darren Hart
2006-06-15 21:06 ` Mike Kravetz
2006-06-15 22:13 ` Darren Hart
2006-06-15 23:05 ` Esben Nielsen
2006-06-15 22:48 ` Mike Kravetz
2006-07-11 16:48 ` Mike Kravetz
2006-06-12 20:12 ` Mike Kravetz
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=20060611055828.GA9452@elte.hu \
--to=mingo@elte.hu \
--cc=dvhltc@us.ibm.com \
--cc=linux-kerneL@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.