linux.git/arch/x86/kernel/cpu/intel_cacheinfo.c, branch v3.10

Merge branch 'x86-debug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2013-02-20T04:09:48+00:00

Pull x86/debug changes from Ingo Molnar:
 "Two init annotations and a built-in memtest speedup"

* 'x86-debug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/memtest: Shorten time for tests
  x86: Convert a few mistaken __cpuinit annotations to __init
  x86/EFI: Properly init-annotate BGRT code

x86/intel/cacheinfo: Shut up annoying warning

2013-02-04T10:29:52+00:00

I've been getting the following warning when doing randbuilds
since forever. Now it finally pissed me off just the perfect
amount so that I can fix it.

  arch/x86/kernel/cpu/intel_cacheinfo.c:489:27: warning: ‘cache_disable_0’ defined but not used [-Wunused-variable]
  arch/x86/kernel/cpu/intel_cacheinfo.c:491:27: warning: ‘cache_disable_1’ defined but not used [-Wunused-variable] arch/x86/kernel/cpu/intel_cacheinfo.c:524:27: warning: ‘subcaches’ defined but not used [-Wunused-variable]

It happens because in randconfigs where CONFIG_SYSFS is not set,
the whole sysfs-interface to L3 cache index disabling is
remaining unused and gcc correctly warns about it. Make it
optional, depending on CONFIG_SYSFS too, as is the case with
other sysfs-related machinery in this file.

Signed-off-by: Borislav Petkov 
Cc: Andreas Herrmann 
Link: http://lkml.kernel.org/r/1359969195-27362-1-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar

x86: Convert a few mistaken cpuinit annotations to init

2013-01-24T16:12:19+00:00

The first two are functions serving as initcalls; the SFI one is
only being called from __init code.

Signed-off-by: Jan Beulich 
Link: http://lkml.kernel.org/r/50AFB35102000078000AAECA@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar

x86, cacheinfo: Base cache sharing info on CPUID 0x8000001d on AMD

2012-11-13T19:22:31+00:00

The patch is based on a patch submitted by Hans Rosenfeld.
See http://marc.info/?l=linux-kernel&m=133908777200931

Note that  CPUID Fn8000_001D_EAX slightly differs to Intel's CPUID function 4.

Bits 14-25 contain NumSharingCache. Actual number of cores sharing
           this cache. SW to add value of one to get result.

The corresponding bits on Intel are defined as "maximum number of threads
sharing this cache" (with a "plus 1" encoding).

Thus a different method to determine which cores are sharing a cache
level has to be used.

Signed-off-by: Andreas Herrmann 
Link: http://lkml.kernel.org/r/20121019090209.GG26718@alberich
Signed-off-by: H. Peter Anvin

x86, cacheinfo: Make use of CPUID 0x8000001d for cache information on AMD

2012-11-13T19:22:30+00:00

Rely on CPUID 0x8000001d for cache information when AMD CPUID topology
extensions are available.

Signed-off-by: Andreas Herrmann 
Link: http://lkml.kernel.org/r/20121019090049.GF26718@alberich
Signed-off-by: H. Peter Anvin

x86, cacheinfo: Determine number of cache leafs using CPUID 0x8000001d on AMD

2012-11-13T19:22:29+00:00

CPUID 0x8000001d works quite similar to Intels' CPUID function 4.
Use it to determine number of cache leafs.

Signed-off-by: Andreas Herrmann 
Link: http://lkml.kernel.org/r/20121019085933.GE26718@alberich
Signed-off-by: H. Peter Anvin

x86/cache_info: Use ARRAY_SIZE() in amd_l3_attrs()

2012-10-04T11:28:08+00:00

Using ARRAY_SIZE() is more readable.

Signed-off-by: Dan Carpenter 
Reviewed-by: Srivatsa S. Bhat 
Cc: Shai Fultheim 
Cc: Greg Kroah-Hartman 
Cc: Andreas Herrmann 
Link: http://lkml.kernel.org/r/20121002083409.GM12398@elgon.mountain
Signed-off-by: Ingo Molnar

x86/cache_info: Fix setup of l2/l3 ids

2012-05-07T13:27:37+00:00

On some architectures (such as vSMP), it is possible to have
CPUs with a different number of cores sharing the same cache.

The current implementation implicitly assumes that all CPUs will
have the same number of cores sharing caches, and as a result,
different CPUs can end up with the same l2/l3 ids.

Fix this by masking out the shared cache bits, instead of
shifting the APICID. By doing so, it is guaranteed that the
generated cache ids are always unique.

Signed-off-by: Shai Fultheim 
[ rebased, simplified, and reworded the commit message]
Signed-off-by: Ido Yariv 
Cc: Borislav Petkov 
Cc: Andreas Herrmann 
Cc: Mike Travis 
Cc: Dave Jones 
Link: http://lkml.kernel.org/r/1334873351-31142-1-git-send-email-ido@wizery.com
Signed-off-by: Ingo Molnar

x86, intel_cacheinfo: Fix error return code in amd_set_l3_disable_slot()

2012-04-19T16:30:28+00:00

If the L3 disable slot is already in use, return -EEXIST instead of
-EINVAL. The caller, store_cache_disable(), checks this return value to
print an appropriate warning.

Also, we want to signal with -EEXIST that the current index we're
disabling has actually been already disabled on the node:

$ echo 12 > /sys/devices/system/cpu/cpu3/cache/index3/cache_disable_0
$ echo 12 > /sys/devices/system/cpu/cpu3/cache/index3/cache_disable_0
-bash: echo: write error: File exists
$ echo 12 > /sys/devices/system/cpu/cpu3/cache/index3/cache_disable_1
-bash: echo: write error: File exists
$ echo 12 > /sys/devices/system/cpu/cpu5/cache/index3/cache_disable_1
-bash: echo: write error: File exists

The old code would say

-bash: echo: write error: Invalid argument

for disable slot 1 when playing the example above with no output in
dmesg, which is clearly misleading.

Reported-by: Dan Carpenter 
Signed-off-by: Srivatsa S. Bhat 
Link: http://lkml.kernel.org/r/20120419070053.GB16645@elgon.mountain
[Boris: add testing for the other index too]
Signed-off-by: Borislav Petkov

x86/amd: Fix L1i and L2 cache sharing information for AMD family 15h processors

2012-02-09T08:38:15+00:00

For L1 instruction cache and L2 cache the shared CPU information
is wrong. On current AMD family 15h CPUs those caches are shared
between both cores of a compute unit.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=42607

Signed-off-by: Andreas Herrmann 
Cc: Petkov Borislav 
Cc: Dave Jones 
Cc: 
Link: http://lkml.kernel.org/r/20120208195229.GA17523@alberich.amd.com
Signed-off-by: Ingo Molnar