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 09:36:09 +0200 [thread overview]
Message-ID: <20060611073609.GA12456@elte.hu> (raw)
In-Reply-To: <200606102324.58932.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). 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 :-)
>
> Well it failed in about 14 minutes. The machine was under heavy load
> running another benchmark. I have removed the secondary benchmark and
> am running prio-preempt alone on the same 4 way opteron box. Will
> post again when I know more...
ok - could you try the patch from today (re-attached below)? Maybe that
theoretical scenario i mentioned is only theoretical in theory ;-)
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 7:36 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
2006-06-11 6:37 ` Ingo Molnar
2006-06-11 6:24 ` Darren Hart
2006-06-11 7:36 ` Ingo Molnar [this message]
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=20060611073609.GA12456@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.