Граф коммитов

14 Коммитов

Автор SHA1 Сообщение Дата
Heiko Carstens 097a116c7e s390/cpuinfo: show dynamic and static cpu mhz
Show the dynamic and static cpu mhz of each cpu. Since these values
are per cpu this requires a fundamental extension of the format of
/proc/cpuinfo.

Historically we had only a single line per cpu and a summary at the
top of the file. This format is hardly extendible if we want to add
more per cpu information.

Therefore this patch adds per cpu blocks at the end of /proc/cpuinfo:

cpu             : 0
cpu Mhz dynamic : 5504
cpu Mhz static  : 5504

cpu             : 1
cpu Mhz dynamic : 5504
cpu Mhz static  : 5504

cpu             : 2
cpu Mhz dynamic : 5504
cpu Mhz static  : 5504

cpu             : 3
cpu Mhz dynamic : 5504
cpu Mhz static  : 5504

Right now each block contains only the dynamic and static cpu mhz,
but it can be easily extended like on every other architecture.

This extension is supposed to be compatible with the old format.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-06-13 15:58:17 +02:00
Heiko Carstens 4c07a399f9 s390/cache: remove superfluous locking
With "s390/cpuinfo: simplify locking and skip offline cpus early" we
prevent already that cpus will go away. The additional
get_online_cpus() / put_online_cpus() within show_cacheinfo() is not
needed anymore.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-05-10 13:24:49 +02:00
Heiko Carstens 0b991f5cdc s390/cachinfo: add missing facility check to init_cache_level()
Stephen Powell reported the following crash on a z890 machine:

Kernel BUG at 00000000001219d0 [verbose debug info unavailable]
illegal operation: 0001 ilc:3 [#1] SMP
Krnl PSW : 0704e00180000000 00000000001219d0 (init_cache_level+0x38/0xe0)
	   R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA:3
Krnl Code: 00000000001219c2: a7840056		brc	8,121a6e
	   00000000001219c6: a7190000		lghi	%r1,0
	  #00000000001219ca: eb101000004c	ecag	%r1,%r0,0(%r1)
	  >00000000001219d0: a7390000		lghi	%r3,0
	   00000000001219d4: e310f0a00024	stg	%r1,160(%r15)
	   00000000001219da: a7080000		lhi	%r0,0
	   00000000001219de: a7b9f000		lghi	%r11,-4096
	   00000000001219e2: c0a0002899d9	larl	%r10,634d94
Call Trace:
 [<0000000000478ee2>] detect_cache_attributes+0x2a/0x2b8
 [<000000000097c9b0>] cacheinfo_sysfs_init+0x60/0xc8
 [<00000000001001c0>] do_one_initcall+0x98/0x1c8
 [<000000000094fdc2>] kernel_init_freeable+0x212/0x2d8
 [<000000000062352e>] kernel_init+0x26/0x118
 [<000000000062fd2e>] kernel_thread_starter+0x6/0xc

The illegal operation was executed because of a missing facility check,
which should have made sure that the ECAG execution would only be executed
on machines which have the general-instructions-extension facility
installed.

Reported-and-tested-by: Stephen Powell <zlinuxman@wowway.com>
Cc: stable@vger.kernel.org # v4.0+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-28 08:54:42 +02:00
Heiko Carstens 77bb36e57b s390/cacheinfo: add missing facility check
Git commit d97d929f06 ("s390: move cacheinfo sysfs to generic cacheinfo
infrastructure") removed the general-instructions-extension availability
check before the ecag instruction is executed.
Without this check this may lead to crashes on machines without this facility.
Therefore add the check again where needed.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-04-13 10:46:16 +02:00
Heiko Carstens f4dce5c936 s390/cacheinfo: coding style changes
Just some minor coding style changes, while I had to look at the code.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-02-12 09:37:24 +01:00
Heiko Carstens 4fd4f1c799 s390/cacheinfo: fix shared cpu masks
When testing Sudeep Holla's cache info rework I didn't realize that the
shared cpu masks are broken (all have the same cpu set).
Let's fix this.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-02-12 09:37:24 +01:00
Heiko Carstens 45cce4ccaf s390/cacheinfo: don't use smp_processor_id() in preemptible context
show_cacheinfo() needs to access the cacheinfo structure of any online
cpu. This was done with using smp_processor_id() as in index while in
preemtible context.
This means the cpu could be offline and the data be gone when it would
be accessed.
Better use any online cpu address and protect the data by get_online_cpus()
and put_online_cpus().

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-02-10 10:15:57 +01:00
Sudeep Holla d97d929f06 s390: move cacheinfo sysfs to generic cacheinfo infrastructure
This patch removes the redundant sysfs cacheinfo code by reusing
the newly introduced generic cacheinfo infrastructure through the
commit 246246cbde ("drivers: base: support cpu cache information
interface to userspace via sysfs")

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-01-08 10:02:54 +01:00
Srivatsa S. Bhat 6575080e67 s390, cacheinfo: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:

	get_online_cpus();

	for_each_online_cpu(cpu)
		init_cpu(cpu);

	register_cpu_notifier(&foobar_cpu_notifier);

	put_online_cpus();

This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).

Instead, the correct and race-free way of performing the callback
registration is:

	cpu_notifier_register_begin();

	for_each_online_cpu(cpu)
		init_cpu(cpu);

	/* Note the use of the double underscored version of the API */
	__register_cpu_notifier(&foobar_cpu_notifier);

	cpu_notifier_register_done();

Fix the cacheinfo code in s390 by using this latter form of callback
registration.

Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-20 13:43:41 +01:00
Heiko Carstens 160d378ebc s390/cache: get rid of compile warning
Get rid of this one:

arch/s390/kernel/cache.c: In function 'cache_build_info':
arch/s390/kernel/cache.c:144: warning: 'private' may be used uninitialized
in this function

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-10-24 17:17:06 +02:00
Paul Gortmaker e2741f1758 s390: delete __cpuinit usage from all s390 files
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit  -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings.  In any case, they are temporary and harmless.

This removes all the arch/s390 uses of the __cpuinit macros from
all C files.  Currently s390 does not have any __CPUINIT used in
assembly files.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux390@de.ibm.com
Cc: linux-s390@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-07-14 19:36:53 -04:00
Heiko Carstens d18f99c28b s390/cache: fix data/instruction cache output
The sysfs and procfs output of the instruction and data caches were
wrong: the output of the data cache provided that instruction cache
values and vice versa.
Fix this by using the correct type indication when issueing the
ecag instruction.

Reported-by: Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-10-18 17:50:11 +02:00
Heiko Carstens 6668022c7b s390/cache: add cpu cache information to /proc/cpuinfo
Add a line for each cpu cache to /proc/cpuinfo.
Since we only have information of private cpu caches in sysfs we
add a line for each cpu cache in /proc/cpuinfo which will also
contain information about shared caches.

For a z196 machine /proc/cpuinfo now looks like:

vendor_id       : IBM/S390
bogomips per cpu: 14367.00
features        : esan3 zarch stfle msa ldisp eimm dfp etf3eh highgprs
cache0          : level=1 type=Data scope=Private size=64K line_size=256 associativity=4
cache1          : level=1 type=Instruction scope=Private size=128K line_size=256 associativity=8
cache2          : level=2 type=Unified scope=Private size=1536K line_size=256 associativity=12
cache3          : level=3 type=Unified scope=Shared size=24576K line_size=256 associativity=12
cache4          : level=4 type=Unified scope=Shared size=196608K line_size=256 associativity=24
processor 0: version = FF,  identification = 000123,  machine = 2817
processor 1: version = FF,  identification = 100123,  machine = 2817
processor 2: version = FF,  identification = 200123,  machine = 2817
processor 3: version = FF,  identification = 200123,  machine = 2817

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-09-26 15:45:03 +02:00
Heiko Carstens 881730ad36 s390/cache: expose cpu cache topology via sysfs
Expose cpu cache topology via sysfs.
The created sysfs directory structure is compatible to what x86, ia64
and powerpc have.
On s390 we expose only information about cpu caches which are private
to a cpu via sysfs . Caches which are shared between cpus do not have
a sysfs representation.
The reason for that is that the file "shared_cpu_map" is mandatory
and only if running under LPAR it is possible to tell which cpus
share which cache. Second level hypervisors however do not and cannot
expose that information to guests.
In order to have a consistent view we made the choice to always only
expose information about private cpu caches via sysfs.

Example for a z196 cpu (cpu1 in /sys/devices/cpu):

cpu1/cache/index0/size -- 64K
cpu1/cache/index0/type -- Data
cpu1/cache/index0/level -- 1
cpu1/cache/index0/number_of_sets -- 64
cpu1/cache/index0/shared_cpu_map -- 00000000,00000002
cpu1/cache/index0/shared_cpu_list -- 1
cpu1/cache/index0/coherency_line_size -- 256
cpu1/cache/index0/ways_of_associativity -- 4
cpu1/cache/index1/size -- 128K
cpu1/cache/index1/type -- Instruction
cpu1/cache/index1/level -- 1
cpu1/cache/index1/number_of_sets -- 64
cpu1/cache/index1/shared_cpu_map -- 00000000,00000002
cpu1/cache/index1/shared_cpu_list -- 1
cpu1/cache/index1/coherency_line_size -- 256
cpu1/cache/index1/ways_of_associativity -- 8
cpu1/cache/index2/size -- 1536K
cpu1/cache/index2/type -- Unified
cpu1/cache/index2/level -- 2
cpu1/cache/index2/number_of_sets -- 512
cpu1/cache/index2/shared_cpu_map -- 00000000,00000002
cpu1/cache/index2/shared_cpu_list -- 1
cpu1/cache/index2/coherency_line_size -- 256
cpu1/cache/index2/ways_of_associativity -- 12

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-09-26 15:44:51 +02:00