linux-kernel - i915.ko WC writes are slow after ea8596bb2d8d379

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 8 Oct 2014 10:03:36 +0100
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	linux-kernel@...r.kernel.org
Cc:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Jiri Kosina <jkosina@...e.cz>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jason Baron <jbaron@...mai.com>, yrl.pp-manager.tt@...achi.com,
	Borislav Petkov <bpetkov@...e.de>,
	Ingo Molnar <mingo@...nel.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>
Subject: i915.ko WC writes are slow after ea8596bb2d8d379


I ran into a problem on a Sandybridge i5-2500s whilst measuring the
performance of GTT write-combining access. I found subsequent runs were
about 10-40x slower than the first. For example,

igt/gem_gtt_speed:

Time to read 16k through a GTT map:             325.285µs
Time to write 16k through a GTT map:              4.729µs
Time to clear 16k through a GTT map:              4.584µs
Time to clear 16k through a cached GTT map:       1.342µs

on the second run became:

Time to read 16k through a GTT map:             332.148µs
Time to write 16k through a GTT map:            209.411µs
Time to clear 16k through a GTT map:             56.460µs
Time to clear 16k through a cached GTT map:      50.897µs

Naively I would say that we lost the wc on our ioremap.
/sys/kernel/debug/x86/pat_memtype_list remained the same across repeated
runs.

A bisection pointed to 

commit ea8596bb2d8d37957f3e92db9511c50801689180
Author: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Date:   Thu Jul 18 20:47:53 2013 +0900

    kprobes/x86: Remove unused text_poke_smp() and text_poke_smp_batch() functions

of which the active ingredient was 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 adding that back into the current build, e.g.

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 regression.

For the record, this kernel build doesn't use modules, which seems relevant
in light of ea8596bb2 "fixes a Kconfig dependency issue on STOP_MACHINE
in the case of CONFIG_SMP && !CONFIG_MODULE_UNLOAD".
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
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/