[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1422028412.6345.6.camel@tkhai>
Date: Fri, 23 Jan 2015 18:53:32 +0300
From: Kirill Tkhai <ktkhai@...allels.com>
To: <linux-kernel@...r.kernel.org>
CC: Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: [RFC] sched, x86: Prevent resched interrupts if task in kernel mode
and !CONFIG_PREEMPT
It's useless to send reschedule interrupts in such situations. The earliest
point, where schedule() call is possible, is sysret_careful(). But in that
function we directly test TIF_NEED_RESCHED.
So it's possible to get rid of that type of interrupts.
How about this idea? Is set_bit() cheap on x86 machines?
---
arch/x86/kernel/entry_64.S | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index c653dc4..a046ba8 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -409,6 +409,13 @@ GLOBAL(system_call_after_swapgs)
movq_cfi rax,(ORIG_RAX-ARGOFFSET)
movq %rcx,RIP-ARGOFFSET(%rsp)
CFI_REL_OFFSET rip,RIP-ARGOFFSET
+#if !defined(CONFIG_PREEMPT) || !defined(SMP)
+ /*
+ * Tell resched_curr() do not send useless interrupts to us.
+ * Kernel isn't preemptible till sysret_careful() anyway.
+ */
+ LOCK ; bts $TIF_POLLING_NRFLAG,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+#endif
testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
jnz tracesys
system_call_fastpath:
@@ -427,6 +434,9 @@ GLOBAL(system_call_after_swapgs)
* Has incomplete stack frame and undefined top of stack.
*/
ret_from_sys_call:
+#if !defined(CONFIG_PREEMPT) || !defined(SMP)
+ LOCK ; btr $TIF_POLLING_NRFLAG,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+#endif
movl $_TIF_ALLWORK_MASK,%edi
/* edi: flagmask */
sysret_check:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists