commit ea8596bb2d8d37957f3e92db9511c50801689180 Author: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Date: Thu Jul 18 20:47:53 2013 +0900 kprobes/x86: Remove unused text_poke_smp() and text_poke_smp_batch() functions Since introducing the text_poke_bp() for all text_poke_smp*() callers, text_poke_smp*() are now unused. This patch basically reverts: 3d55cc8a058e ("x86: Add text_poke_smp for SMP cross modifying code") 7deb18dcf047 ("x86: Introduce text_poke_smp_batch() for batch-code modifying") and related commits. This patch also fixes a Kconfig dependency issue on STOP_MACHINE in the case of CONFIG_SMP && !CONFIG_MODULE_UNLOAD. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Reviewed-by: Jiri Kosina <jkosina@suse.cz> Cc: H. Peter Anvin <hpa@linux.intel.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Jason Baron <jbaron@akamai.com> Cc: yrl.pp-manager.tt@hitachi.com Cc: Borislav Petkov <bpetkov@suse.de> Link: http://lkml.kernel.org/r/20130718114753.26675.18714.stgit@mhiramat-M0-7522 Signed-off-by: Ingo Molnar <mingo@kernel.org> (bisected and manually checked) This patch appears to make repeated access through the GTT extremely slow (roughly equivalent to uc access I would say). This is demonstrated by igt/gem_gtt_speed, and affects everything using X and mesa ???
The active ingredient is just diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index b32ebf9..f4001e0 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2334,7 +2334,6 @@ config HAVE_ATOMIC_IOMAP config HAVE_TEXT_POKE_SMP bool - select STOP_MACHINE if SMP config X86_DEV_DMA_OPS bool
And correspondingly diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 3632743..48a8a69 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -87,6 +87,7 @@ config X86 select HAVE_USER_RETURN_NOTIFIER select ARCH_BINFMT_ELF_RANDOMIZE_PIE select HAVE_ARCH_JUMP_LABEL + select STOP_MACHINE select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select SPARSE_IRQ select GENERIC_FIND_FIRST_BIT fixes the current kernel.
So what exactly is the action plan here? Report the "regression" of the kprobes patch? Propose changes to the default x86 config parameters? Fix i915.ko somehow?
Oh, fdo. I added a link to the upstream report [https://lkml.org/lkml/2014/10/8/124]
(In reply to Chris Wilson from comment #4) > Oh, fdo. I added a link to the upstream report > [https://lkml.org/lkml/2014/10/8/124] Seems to have stalled, what next?
Giving this one to Peter as he touched it on lkml. :) Sounds like a core x86 issue at any rate.
Still affecting current kernels (4.2-rc3).
Created attachment 117380 [details] [review] x86 mttr bogon
commit 86fffe4a61dd972d5a4e23260d530be6da02f614 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Dec 11 13:40:46 2015 -0800 kernel: remove stop_machine() Kconfig dependency Currently the full stop_machine() routine is only enabled on SMP if module unloading is enabled, or if the CPUs are hotpluggable. This leads to configurations where stop_machine() is broken as it will then only run the callback on the local CPU with irqs disabled, and not stop the other CPUs or run the callback on them. For example, this breaks MTRR setup on x86 in certain configs since ea8596bb2d8d379 ("kprobes/x86: Remove unused text_poke_smp() and text_poke_smp_batch() functions") as the MTRR is only established on the boot CPU. This patch removes the Kconfig option for STOP_MACHINE and uses the SMP and HOTPLUG_CPU config options to compile the correct stop_machine() for the architecture, removing the false dependency on MODULE_UNLOAD in the process. Link: https://lkml.org/lkml/2014/10/8/124 References: https://bugs.freedesktop.org/show_bug.cgi?id=84794
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.