sched_clock() should be fast, scalable and not use any lock. As a
resuly it should be safely called from NMIs.
Now just in case there might be some implementation details proper
to some archs that make sched_clock() not reliable or not safe in NMIs,
lets provide a way through Kconfig for archs to testify about that
support.
Signed-off-by: Frederic Weisbecker <fweis...@gmail.com>
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com>
Cc: John Stultz <john.stu...@linaro.org>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Don Zickus <dzic...@redhat.com>
---
arch/Kconfig | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 1feb169..52ad235 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -393,6 +393,11 @@ config HAVE_UNDERSCORE_SYMBOL_PREFIX
Some architectures generate an _ in front of C symbols; things like
module loading and assembly files need to know about this.
+config HAVE_SCHED_CLOCK_NMI
+ bool
+ help
+ Architecture's sched_clock() implementation is safely callable from
NMIs.
+
#
# ABI hall of shame
#
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
