From: Nicholas Mc Guire <der.herr@hofr.at>
To: linux-rt-users@vger.kernel.org
Cc: LKML <linux-kernel@vger.kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Carsten Emde <C.Emde@osadl.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andreas Platschek <platschek@ict.tuwien.ac.at>
Subject: allow preemption in check_task_state
Date: Mon, 10 Feb 2014 16:38:56 +0100 [thread overview]
Message-ID: <20140210153856.GD20017@opentech.at> (raw)
A lockfree approach to check_task_state
This treates the state as an indicator variable and use it to probe
saved_state lock free. There is actually no consistency demand on
state/saved_state but rather a consistency demand on the transitions
of the two variables but those transition, based on path inspection,
are not independent.
Its probably not faster than the lock/unlock case if uncontended - atleast
it does not show up in benchmark results, but it would never be hit by a
full pi-boost cycle as there is no contention.
This also was tested against the test-case from Sebastian as well as
rnning a few scripted gdb breakpoint debugging/single-stepping loops
to trigger this.
Tested-by: Andreas Platschek <platschek@ict.tuwien.ac.at>
Tested-by: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
---
kernel/sched/core.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index bf93f63..5690ba3 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1074,11 +1074,17 @@ static int migration_cpu_stop(void *data);
static bool check_task_state(struct task_struct *p, long match_state)
{
bool match = false;
+ long state, saved_state;
+
+ /* catch restored state */
+ do {
+ state = p->state;
+ saved_state = p->saved_state;
+ rmb(); /* make sure we actually catch updates */
+ } while (state != p->state);
- raw_spin_lock_irq(&p->pi_lock);
if (p->state == match_state || p->saved_state == match_state)
match = true;
- raw_spin_unlock_irq(&p->pi_lock);
return match;
}
--
1.7.2.5
next reply other threads:[~2014-02-10 15:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-10 15:38 Nicholas Mc Guire [this message]
2014-02-10 16:11 ` allow preemption in check_task_state Steven Rostedt
2014-02-10 17:17 ` Nicholas Mc Guire
2014-02-10 17:38 ` Peter Zijlstra
2014-02-10 18:12 ` Nicholas Mc Guire
2014-02-10 18:16 ` Peter Zijlstra
2014-02-10 18:45 ` Nicholas Mc Guire
2014-02-10 17:52 ` Steven Rostedt
2014-02-10 18:13 ` Nicholas Mc Guire
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=20140210153856.GD20017@opentech.at \
--to=der.herr@hofr.at \
--cc=C.Emde@osadl.org \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=platschek@ict.tuwien.ac.at \
--cc=rostedt@goodmis.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.