x86, mm: dont use non-temporal stores in pagecache accesses
authorIngo Molnar <mingo@elte.hu>
Mon, 2 Mar 2009 10:00:57 +0000 (11:00 +0100)
committerIngo Molnar <mingo@elte.hu>
Mon, 2 Mar 2009 10:06:49 +0000 (11:06 +0100)
commitf180053694b43d5714bf56cb95499a3c32ff155c
tree00286fcc88d2842629b039da4009a1332b3a1719
parent34754b69a6f87aa6aa2860525a82f12532f83afd
x86, mm: dont use non-temporal stores in pagecache accesses

Impact: standardize IO on cached ops

On modern CPUs it is almost always a bad idea to use non-temporal stores,
as the regression in this commit has shown it:

  30d697f: x86: fix performance regression in write() syscall

The kernel simply has no good information about whether using non-temporal
stores is a good idea or not - and trying to add heuristics only increases
complexity and inserts fragility.

The regression on cached write()s took very long to be found - over two
years. So dont take any chances and let the hardware decide how it makes
use of its caches.

The only exception is drivers/gpu/drm/i915/i915_gem.c: there were we are
absolutely sure that another entity (the GPU) will pick up the dirty
data immediately and that the CPU will not touch that data before the
GPU will.

Also, keep the _nocache() primitives to make it easier for people to
experiment with these details. There may be more clear-cut cases where
non-cached copies can be used, outside of filemap.c.

Cc: Salman Qazi <sqazi@google.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
arch/x86/include/asm/uaccess_32.h
arch/x86/include/asm/uaccess_64.h
drivers/gpu/drm/i915/i915_gem.c
include/linux/uaccess.h
mm/filemap.c
mm/filemap_xip.c