2019-05-27 08:55:01 +02:00
// SPDX-License-Identifier: GPL-2.0-or-later
2005-04-16 15:20:36 -07:00
/*
* SMP support for ppc .
*
* Written by Cort Dougan ( cort @ cs . nmt . edu ) borrowing a great
* deal of code from the sparc and intel versions .
*
* Copyright ( C ) 1999 Cort Dougan < cort @ cs . nmt . edu >
*
* PowerPC - 64 Support added by Dave Engebretsen , Peter Bergner , and
* Mike Corrigan { engebret | bergner | mikec } @ us . ibm . com
*/
# undef DEBUG
# include <linux/kernel.h>
2011-07-22 18:24:23 -04:00
# include <linux/export.h>
2017-02-01 19:08:20 +01:00
# include <linux/sched/mm.h>
2019-01-17 23:26:56 +11:00
# include <linux/sched/task_stack.h>
2017-02-01 16:36:40 +01:00
# include <linux/sched/topology.h>
2005-04-16 15:20:36 -07:00
# include <linux/smp.h>
# include <linux/interrupt.h>
# include <linux/delay.h>
# include <linux/init.h>
# include <linux/spinlock.h>
# include <linux/cache.h>
# include <linux/err.h>
2011-12-21 14:29:42 -08:00
# include <linux/device.h>
2005-04-16 15:20:36 -07:00
# include <linux/cpu.h>
# include <linux/notifier.h>
2005-12-13 06:56:47 +11:00
# include <linux/topology.h>
2016-05-18 11:16:51 +10:00
# include <linux/profile.h>
2017-06-06 23:08:32 +10:00
# include <linux/processor.h>
2018-10-13 09:45:12 +00:00
# include <linux/random.h>
2018-10-19 16:19:10 +11:00
# include <linux/stackprotector.h>
2020-06-08 21:32:42 -07:00
# include <linux/pgtable.h>
2021-01-04 15:31:51 +01:00
# include <linux/clockchips.h>
2005-04-16 15:20:36 -07:00
# include <asm/ptrace.h>
2011-07-26 16:09:06 -07:00
# include <linux/atomic.h>
2005-04-16 15:20:36 -07:00
# include <asm/irq.h>
2014-02-26 05:37:43 +05:30
# include <asm/hw_irq.h>
2014-05-23 18:15:25 +10:00
# include <asm/kvm_ppc.h>
2017-04-13 20:16:21 +10:00
# include <asm/dbell.h>
2005-04-16 15:20:36 -07:00
# include <asm/page.h>
# include <asm/prom.h>
# include <asm/smp.h>
# include <asm/time.h>
# include <asm/machdep.h>
2008-07-27 15:24:52 +10:00
# include <asm/cputhreads.h>
2005-04-16 15:20:36 -07:00
# include <asm/cputable.h>
2005-09-27 13:51:59 +10:00
# include <asm/mpic.h>
2005-11-11 21:15:21 +11:00
# include <asm/vdso_datapage.h>
2005-11-05 10:33:55 +11:00
# ifdef CONFIG_PPC64
# include <asm/paca.h>
# endif
2012-07-04 20:37:11 +00:00
# include <asm/vdso.h>
2012-03-28 18:30:02 +01:00
# include <asm/debug.h>
2014-08-20 08:55:19 +10:00
# include <asm/kexec.h>
2016-05-18 11:16:50 +10:00
# include <asm/asm-prototypes.h>
2016-07-23 14:42:40 +05:30
# include <asm/cpu_has_feature.h>
2018-04-19 12:34:03 +05:30
# include <asm/ftrace.h>
2020-07-09 08:59:42 +05:30
# include <asm/kup.h>
2005-11-05 10:33:55 +11:00
2005-04-16 15:20:36 -07:00
# ifdef DEBUG
2005-11-15 15:16:38 +11:00
# include <asm/udbg.h>
2005-04-16 15:20:36 -07:00
# define DBG(fmt...) udbg_printf(fmt)
# else
# define DBG(fmt...)
# endif
2011-03-08 14:40:04 +11:00
# ifdef CONFIG_HOTPLUG_CPU
2011-09-19 17:44:49 +00:00
/* State of each CPU during hotplug phases */
static DEFINE_PER_CPU ( int , cpu_state ) = { 0 } ;
2011-03-08 14:40:04 +11:00
# endif
2019-01-31 10:09:02 +00:00
struct task_struct * secondary_current ;
2018-10-11 11:03:01 +05:30
bool has_big_cores ;
2020-08-10 12:48:31 +05:30
bool coregroup_enabled ;
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
bool thread_group_shares_l2 ;
2021-07-28 23:26:07 +05:30
bool thread_group_shares_l3 ;
2005-11-15 15:16:38 +11:00
2010-04-26 15:32:41 +00:00
DEFINE_PER_CPU ( cpumask_var_t , cpu_sibling_map ) ;
2018-10-11 11:03:01 +05:30
DEFINE_PER_CPU ( cpumask_var_t , cpu_smallcore_map ) ;
2017-06-29 17:12:55 +10:00
DEFINE_PER_CPU ( cpumask_var_t , cpu_l2_cache_map ) ;
2010-04-26 15:32:41 +00:00
DEFINE_PER_CPU ( cpumask_var_t , cpu_core_map ) ;
2021-04-07 20:59:03 +08:00
static DEFINE_PER_CPU ( cpumask_var_t , cpu_coregroup_map ) ;
2005-04-16 15:20:36 -07:00
2007-10-16 01:24:05 -07:00
EXPORT_PER_CPU_SYMBOL ( cpu_sibling_map ) ;
2017-06-29 17:12:55 +10:00
EXPORT_PER_CPU_SYMBOL ( cpu_l2_cache_map ) ;
2008-07-27 15:24:53 +10:00
EXPORT_PER_CPU_SYMBOL ( cpu_core_map ) ;
2018-10-11 11:03:01 +05:30
EXPORT_SYMBOL_GPL ( has_big_cores ) ;
2020-08-10 12:48:33 +05:30
enum {
# ifdef CONFIG_SCHED_SMT
smt_idx ,
# endif
cache_idx ,
mc_idx ,
die_idx ,
} ;
2018-10-11 11:03:01 +05:30
# define MAX_THREAD_LIST_SIZE 8
# define THREAD_GROUP_SHARE_L1 1
2021-07-28 23:26:07 +05:30
# define THREAD_GROUP_SHARE_L2_L3 2
2018-10-11 11:03:01 +05:30
struct thread_groups {
unsigned int property ;
unsigned int nr_groups ;
unsigned int threads_per_group ;
unsigned int thread_list [ MAX_THREAD_LIST_SIZE ] ;
} ;
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
/* Maximum number of properties that groups of threads within a core can share */
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
# define MAX_THREAD_GROUP_PROPERTIES 2
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
struct thread_groups_list {
unsigned int nr_properties ;
struct thread_groups property_tgs [ MAX_THREAD_GROUP_PROPERTIES ] ;
} ;
static struct thread_groups_list tgl [ NR_CPUS ] __initdata ;
2018-10-11 11:03:01 +05:30
/*
2020-12-10 16:08:56 +05:30
* On big - cores system , thread_group_l1_cache_map for each CPU corresponds to
2018-10-11 11:03:01 +05:30
* the set its siblings that share the L1 - cache .
*/
powerpc/cacheinfo: Lookup cache by dt node and thread-group id
Currently the cacheinfo code on powerpc indexes the "cache" objects
(modelling the L1/L2/L3 caches) where the key is device-tree node
corresponding to that cache. On some of the POWER server platforms
thread-groups within the core share different sets of caches (Eg: On
SMT8 POWER9 systems, threads 0,2,4,6 of a core share L1 cache and
threads 1,3,5,7 of the same core share another L1 cache). On such
platforms, there is a single device-tree node corresponding to that
cache and the cache-configuration within the threads of the core is
indicated via "ibm,thread-groups" device-tree property.
Since the current code is not aware of the "ibm,thread-groups"
property, on the aforementoined systems, cacheinfo code still treats
all the threads in the core to be sharing the cache because of the
single device-tree node (In the earlier example, the cacheinfo code
would says CPUs 0-7 share L1 cache).
In this patch, we make the powerpc cacheinfo code aware of the
"ibm,thread-groups" property. We indexe the "cache" objects by the
key-pair (device-tree node, thread-group id). For any CPUX, for a
given level of cache, the thread-group id is defined to be the first
CPU in the "ibm,thread-groups" cache-group containing CPUX. For levels
of cache which are not represented in "ibm,thread-groups" property,
the thread-group id is -1.
[parth: Remove "static" keyword for the definition of "thread_group_l1_cache_map"
and "thread_group_l2_cache_map" to get rid of the compile error.]
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Parth Shah <parth@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210728175607.591679-2-parth@linux.ibm.com
2021-07-28 23:26:05 +05:30
DEFINE_PER_CPU ( cpumask_var_t , thread_group_l1_cache_map ) ;
2005-04-16 15:20:36 -07:00
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
/*
* On some big - cores system , thread_group_l2_cache_map for each CPU
* corresponds to the set its siblings within the core that share the
* L2 - cache .
*/
powerpc/cacheinfo: Lookup cache by dt node and thread-group id
Currently the cacheinfo code on powerpc indexes the "cache" objects
(modelling the L1/L2/L3 caches) where the key is device-tree node
corresponding to that cache. On some of the POWER server platforms
thread-groups within the core share different sets of caches (Eg: On
SMT8 POWER9 systems, threads 0,2,4,6 of a core share L1 cache and
threads 1,3,5,7 of the same core share another L1 cache). On such
platforms, there is a single device-tree node corresponding to that
cache and the cache-configuration within the threads of the core is
indicated via "ibm,thread-groups" device-tree property.
Since the current code is not aware of the "ibm,thread-groups"
property, on the aforementoined systems, cacheinfo code still treats
all the threads in the core to be sharing the cache because of the
single device-tree node (In the earlier example, the cacheinfo code
would says CPUs 0-7 share L1 cache).
In this patch, we make the powerpc cacheinfo code aware of the
"ibm,thread-groups" property. We indexe the "cache" objects by the
key-pair (device-tree node, thread-group id). For any CPUX, for a
given level of cache, the thread-group id is defined to be the first
CPU in the "ibm,thread-groups" cache-group containing CPUX. For levels
of cache which are not represented in "ibm,thread-groups" property,
the thread-group id is -1.
[parth: Remove "static" keyword for the definition of "thread_group_l1_cache_map"
and "thread_group_l2_cache_map" to get rid of the compile error.]
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Parth Shah <parth@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210728175607.591679-2-parth@linux.ibm.com
2021-07-28 23:26:05 +05:30
DEFINE_PER_CPU ( cpumask_var_t , thread_group_l2_cache_map ) ;
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
2021-07-28 23:26:07 +05:30
/*
* On P10 , thread_group_l3_cache_map for each CPU is equal to the
* thread_group_l2_cache_map
*/
DEFINE_PER_CPU ( cpumask_var_t , thread_group_l3_cache_map ) ;
2005-11-05 10:33:55 +11:00
/* SMP operations for this machine */
2005-04-16 15:20:36 -07:00
struct smp_ops_t * smp_ops ;
2009-06-18 23:30:07 +00:00
/* Can't be static due to PowerMac hackery */
volatile unsigned int cpu_callin_map [ NR_CPUS ] ;
2005-04-16 15:20:36 -07:00
int smt_enabled_at_boot = 1 ;
2013-08-05 14:58:34 -05:00
/*
* Returns 1 if the specified cpu should be brought up during boot .
* Used to inhibit booting threads if they ' ve been disabled or
* limited on the command line
*/
int smp_generic_cpu_bootable ( unsigned int nr )
{
/* Special case - we inhibit secondary thread startup
* during boot if the user requests it .
*/
2017-05-16 20:42:37 +02:00
if ( system_state < SYSTEM_RUNNING & & cpu_has_feature ( CPU_FTR_SMT ) ) {
2013-08-05 14:58:34 -05:00
if ( ! smt_enabled_at_boot & & cpu_thread_in_core ( nr ) ! = 0 )
return 0 ;
if ( smt_enabled_at_boot
& & cpu_thread_in_core ( nr ) > = smt_enabled_at_boot )
return 0 ;
}
return 1 ;
}
2005-11-05 10:33:55 +11:00
# ifdef CONFIG_PPC64
2012-12-21 14:04:10 -08:00
int smp_generic_kick_cpu ( int nr )
2005-04-16 15:20:36 -07:00
{
2017-06-27 12:30:06 +05:30
if ( nr < 0 | | nr > = nr_cpu_ids )
2017-06-27 12:30:05 +05:30
return - EINVAL ;
2005-04-16 15:20:36 -07:00
/*
* The processor is currently spinning , waiting for the
* cpu_start field to become non - zero After we set cpu_start ,
* the processor will continue on to secondary_start
*/
2018-02-14 01:08:12 +10:00
if ( ! paca_ptrs [ nr ] - > cpu_start ) {
paca_ptrs [ nr ] - > cpu_start = 1 ;
2011-09-19 17:44:49 +00:00
smp_mb ( ) ;
return 0 ;
}
# ifdef CONFIG_HOTPLUG_CPU
/*
* Ok it ' s not there , so it might be soft - unplugged , let ' s
* try to bring it back
*/
2012-07-20 20:42:34 +08:00
generic_set_cpu_up ( nr ) ;
2011-09-19 17:44:49 +00:00
smp_wmb ( ) ;
smp_send_reschedule ( nr ) ;
# endif /* CONFIG_HOTPLUG_CPU */
2011-04-11 21:46:19 +00:00
return 0 ;
2005-04-16 15:20:36 -07:00
}
2011-09-19 17:44:49 +00:00
# endif /* CONFIG_PPC64 */
2005-04-16 15:20:36 -07:00
2008-11-14 20:11:49 +00:00
static irqreturn_t call_function_action ( int irq , void * data )
{
generic_smp_call_function_interrupt ( ) ;
return IRQ_HANDLED ;
}
static irqreturn_t reschedule_action ( int irq , void * data )
{
2011-04-05 17:23:39 +02:00
scheduler_ipi ( ) ;
2008-11-14 20:11:49 +00:00
return IRQ_HANDLED ;
}
2018-05-05 03:19:33 +10:00
# ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
2014-02-26 05:37:43 +05:30
static irqreturn_t tick_broadcast_ipi_action ( int irq , void * data )
2008-11-14 20:11:49 +00:00
{
2018-05-05 03:19:31 +10:00
timer_broadcast_interrupt ( ) ;
2008-11-14 20:11:49 +00:00
return IRQ_HANDLED ;
}
2018-05-05 03:19:33 +10:00
# endif
2008-11-14 20:11:49 +00:00
2016-12-20 04:30:08 +10:00
# ifdef CONFIG_NMI_IPI
static irqreturn_t nmi_ipi_action ( int irq , void * data )
2008-11-14 20:11:49 +00:00
{
2016-12-20 04:30:08 +10:00
smp_handle_nmi_ipi ( get_irq_regs ( ) ) ;
2008-11-14 20:11:49 +00:00
return IRQ_HANDLED ;
}
2016-12-20 04:30:08 +10:00
# endif
2008-11-14 20:11:49 +00:00
static irq_handler_t smp_ipi_action [ ] = {
[ PPC_MSG_CALL_FUNCTION ] = call_function_action ,
[ PPC_MSG_RESCHEDULE ] = reschedule_action ,
2018-05-05 03:19:33 +10:00
# ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
2014-02-26 05:37:43 +05:30
[ PPC_MSG_TICK_BROADCAST ] = tick_broadcast_ipi_action ,
2018-05-05 03:19:33 +10:00
# endif
2016-12-20 04:30:08 +10:00
# ifdef CONFIG_NMI_IPI
[ PPC_MSG_NMI_IPI ] = nmi_ipi_action ,
# endif
2008-11-14 20:11:49 +00:00
} ;
2016-12-20 04:30:08 +10:00
/*
* The NMI IPI is a fallback and not truly non - maskable . It is simpler
* than going through the call function infrastructure , and strongly
* serialized , so it is more appropriate for debugging .
*/
2008-11-14 20:11:49 +00:00
const char * smp_ipi_name [ ] = {
[ PPC_MSG_CALL_FUNCTION ] = " ipi call function " ,
[ PPC_MSG_RESCHEDULE ] = " ipi reschedule " ,
2018-05-05 03:19:33 +10:00
# ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
2014-02-26 05:37:43 +05:30
[ PPC_MSG_TICK_BROADCAST ] = " ipi tick-broadcast " ,
2018-05-05 03:19:33 +10:00
# endif
2018-05-05 03:19:34 +10:00
# ifdef CONFIG_NMI_IPI
2016-12-20 04:30:08 +10:00
[ PPC_MSG_NMI_IPI ] = " nmi ipi " ,
2018-05-05 03:19:34 +10:00
# endif
2008-11-14 20:11:49 +00:00
} ;
/* optional function to request ipi, for controllers with >= 4 ipis */
int smp_request_message_ipi ( int virq , int msg )
{
int err ;
2016-12-20 04:30:08 +10:00
if ( msg < 0 | | msg > PPC_MSG_NMI_IPI )
2008-11-14 20:11:49 +00:00
return - EINVAL ;
2016-12-20 04:30:08 +10:00
# ifndef CONFIG_NMI_IPI
if ( msg = = PPC_MSG_NMI_IPI )
2008-11-14 20:11:49 +00:00
return 1 ;
# endif
2016-12-20 04:30:08 +10:00
2011-10-05 02:30:50 +00:00
err = request_irq ( virq , smp_ipi_action [ msg ] ,
2012-07-20 20:47:01 +08:00
IRQF_PERCPU | IRQF_NO_THREAD | IRQF_NO_SUSPEND ,
2013-08-07 02:01:24 +10:00
smp_ipi_name [ msg ] , NULL ) ;
2008-11-14 20:11:49 +00:00
WARN ( err < 0 , " unable to request_irq %d for %s (rc %d) \n " ,
virq , smp_ipi_name [ msg ] , err ) ;
return err ;
}
2011-05-10 19:29:42 +00:00
# ifdef CONFIG_PPC_SMP_MUXED_IPI
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
struct cpu_messages {
2015-12-17 14:59:03 -06:00
long messages ; /* current messages */
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
} ;
static DEFINE_PER_CPU_SHARED_ALIGNED ( struct cpu_messages , ipi_message ) ;
2015-12-17 14:59:04 -06:00
void smp_muxed_ipi_set_message ( int cpu , int msg )
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
{
struct cpu_messages * info = & per_cpu ( ipi_message , cpu ) ;
2011-05-10 19:29:46 +00:00
char * message = ( char * ) & info - > messages ;
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
2012-09-04 18:33:08 +00:00
/*
* Order previous accesses before accesses in the IPI handler .
*/
smp_mb ( ) ;
2011-05-10 19:29:46 +00:00
message [ msg ] = 1 ;
2015-12-17 14:59:04 -06:00
}
void smp_muxed_ipi_message_pass ( int cpu , int msg )
{
smp_muxed_ipi_set_message ( cpu , msg ) ;
2017-04-13 20:16:21 +10:00
2012-09-04 18:33:08 +00:00
/*
* cause_ipi functions are required to include a full barrier
* before doing whatever causes the IPI .
*/
2017-04-13 20:16:21 +10:00
smp_ops - > cause_ipi ( cpu ) ;
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
}
2013-08-07 02:01:48 +10:00
# ifdef __BIG_ENDIAN__
2015-12-17 14:59:03 -06:00
# define IPI_MESSAGE(A) (1uL << ((BITS_PER_LONG - 8) - 8 * (A)))
2013-08-07 02:01:48 +10:00
# else
2015-12-17 14:59:03 -06:00
# define IPI_MESSAGE(A) (1uL << (8 * (A)))
2013-08-07 02:01:48 +10:00
# endif
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
irqreturn_t smp_ipi_demux ( void )
{
mb ( ) ; /* order any irq clear */
2011-05-10 19:29:46 +00:00
2017-04-13 20:16:22 +10:00
return smp_ipi_demux_relaxed ( ) ;
}
/* sync-free variant. Callers should ensure synchronization */
irqreturn_t smp_ipi_demux_relaxed ( void )
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
{
2017-04-13 20:16:21 +10:00
struct cpu_messages * info ;
2015-12-17 14:59:03 -06:00
unsigned long all ;
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
2017-04-13 20:16:21 +10:00
info = this_cpu_ptr ( & ipi_message ) ;
2011-05-10 19:29:46 +00:00
do {
2012-09-04 18:33:08 +00:00
all = xchg ( & info - > messages , 0 ) ;
2015-12-21 16:22:51 -06:00
# if defined(CONFIG_KVM_XICS) && defined(CONFIG_KVM_BOOK3S_HV_POSSIBLE)
/*
* Must check for PPC_MSG_RM_HOST_ACTION messages
* before PPC_MSG_CALL_FUNCTION messages because when
* a VM is destroyed , we call kick_all_cpus_sync ( )
* to ensure that any pending PPC_MSG_RM_HOST_ACTION
* messages have completed before we free any VCPUs .
*/
if ( all & IPI_MESSAGE ( PPC_MSG_RM_HOST_ACTION ) )
kvmppc_xics_ipi_action ( ) ;
# endif
2013-08-07 02:01:48 +10:00
if ( all & IPI_MESSAGE ( PPC_MSG_CALL_FUNCTION ) )
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
generic_smp_call_function_interrupt ( ) ;
2013-08-07 02:01:48 +10:00
if ( all & IPI_MESSAGE ( PPC_MSG_RESCHEDULE ) )
2011-05-20 15:36:52 +10:00
scheduler_ipi ( ) ;
2018-05-05 03:19:33 +10:00
# ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
2014-02-26 05:37:43 +05:30
if ( all & IPI_MESSAGE ( PPC_MSG_TICK_BROADCAST ) )
2018-05-05 03:19:31 +10:00
timer_broadcast_interrupt ( ) ;
2018-05-05 03:19:33 +10:00
# endif
2016-12-20 04:30:08 +10:00
# ifdef CONFIG_NMI_IPI
if ( all & IPI_MESSAGE ( PPC_MSG_NMI_IPI ) )
nmi_ipi_action ( 0 , NULL ) ;
# endif
2011-05-10 19:29:46 +00:00
} while ( info - > messages ) ;
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
return IRQ_HANDLED ;
}
2011-05-10 19:29:42 +00:00
# endif /* CONFIG_PPC_SMP_MUXED_IPI */
powerpc: Consolidate ipi message mux and demux
Consolidate the mux and demux of ipi messages into smp.c and call
a new smp_ops callback to actually trigger the ipi.
The powerpc architecture code is optimised for having 4 distinct
ipi triggers, which are mapped to 4 distinct messages (ipi many, ipi
single, scheduler ipi, and enter debugger). However, several interrupt
controllers only provide a single software triggered interrupt that
can be delivered to each cpu. To resolve this limitation, each smp_ops
implementation created a per-cpu variable that is manipulated with atomic
bitops. Since these lines will be contended they are optimialy marked as
shared_aligned and take a full cache line for each cpu. Distro kernels
may have 2 or 3 of these in their config, each taking per-cpu space
even though at most one will be in use.
This consolidation removes smp_message_recv and replaces the single call
actions cases with direct calls from the common message recognition loop.
The complicated debugger ipi case with its muxed crash handling code is
moved to debug_ipi_action which is now called from the demux code (instead
of the multi-message action calling smp_message_recv).
I put a call to reschedule_action to increase the likelyhood of correctly
merging the anticipated scheduler_ipi() hook coming from the scheduler
tree; that single required call can be inlined later.
The actual message decode is a copy of the old pseries xics code with its
memory barriers and cache line spacing, augmented with a per-cpu unsigned
long based on the book-e doorbell code. The optional data is set via a
callback from the implementation and is passed to the new cause-ipi hook
along with the logical cpu number. While currently only the doorbell
implemntation uses this data it should be almost zero cost to retrieve and
pass it -- it adds a single register load for the argument from the same
cache line to which we just completed a store and the register is dead
on return from the call. I extended the data element from unsigned int
to unsigned long in case some other code wanted to associate a pointer.
The doorbell check_self is replaced by a call to smp_muxed_ipi_resend,
conditioned on the CPU_DBELL feature. The ifdef guard could be relaxed
to CONFIG_SMP but I left it with BOOKE for now.
Also, the doorbell interrupt vector for book-e was not calling irq_enter
and irq_exit, which throws off cpu accounting and causes code to not
realize it is running in interrupt context. Add the missing calls.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-05-10 19:29:39 +00:00
2011-05-25 23:34:12 +00:00
static inline void do_message_pass ( int cpu , int msg )
{
if ( smp_ops - > message_pass )
smp_ops - > message_pass ( cpu , msg ) ;
# ifdef CONFIG_PPC_SMP_MUXED_IPI
else
smp_muxed_ipi_message_pass ( cpu , msg ) ;
# endif
}
2005-04-16 15:20:36 -07:00
void smp_send_reschedule ( int cpu )
{
2006-07-04 14:09:36 +10:00
if ( likely ( smp_ops ) )
2011-05-25 23:34:12 +00:00
do_message_pass ( cpu , PPC_MSG_RESCHEDULE ) ;
2005-04-16 15:20:36 -07:00
}
KVM: PPC: Add support for Book3S processors in hypervisor mode
This adds support for KVM running on 64-bit Book 3S processors,
specifically POWER7, in hypervisor mode. Using hypervisor mode means
that the guest can use the processor's supervisor mode. That means
that the guest can execute privileged instructions and access privileged
registers itself without trapping to the host. This gives excellent
performance, but does mean that KVM cannot emulate a processor
architecture other than the one that the hardware implements.
This code assumes that the guest is running paravirtualized using the
PAPR (Power Architecture Platform Requirements) interface, which is the
interface that IBM's PowerVM hypervisor uses. That means that existing
Linux distributions that run on IBM pSeries machines will also run
under KVM without modification. In order to communicate the PAPR
hypercalls to qemu, this adds a new KVM_EXIT_PAPR_HCALL exit code
to include/linux/kvm.h.
Currently the choice between book3s_hv support and book3s_pr support
(i.e. the existing code, which runs the guest in user mode) has to be
made at kernel configuration time, so a given kernel binary can only
do one or the other.
This new book3s_hv code doesn't support MMIO emulation at present.
Since we are running paravirtualized guests, this isn't a serious
restriction.
With the guest running in supervisor mode, most exceptions go straight
to the guest. We will never get data or instruction storage or segment
interrupts, alignment interrupts, decrementer interrupts, program
interrupts, single-step interrupts, etc., coming to the hypervisor from
the guest. Therefore this introduces a new KVMTEST_NONHV macro for the
exception entry path so that we don't have to do the KVM test on entry
to those exception handlers.
We do however get hypervisor decrementer, hypervisor data storage,
hypervisor instruction storage, and hypervisor emulation assist
interrupts, so we have to handle those.
In hypervisor mode, real-mode accesses can access all of RAM, not just
a limited amount. Therefore we put all the guest state in the vcpu.arch
and use the shadow_vcpu in the PACA only for temporary scratch space.
We allocate the vcpu with kzalloc rather than vzalloc, and we don't use
anything in the kvmppc_vcpu_book3s struct, so we don't allocate it.
We don't have a shared page with the guest, but we still need a
kvm_vcpu_arch_shared struct to store the values of various registers,
so we include one in the vcpu_arch struct.
The POWER7 processor has a restriction that all threads in a core have
to be in the same partition. MMU-on kernel code counts as a partition
(partition 0), so we have to do a partition switch on every entry to and
exit from the guest. At present we require the host and guest to run
in single-thread mode because of this hardware restriction.
This code allocates a hashed page table for the guest and initializes
it with HPTEs for the guest's Virtual Real Memory Area (VRMA). We
require that the guest memory is allocated using 16MB huge pages, in
order to simplify the low-level memory management. This also means that
we can get away without tracking paging activity in the host for now,
since huge pages can't be paged or swapped.
This also adds a few new exports needed by the book3s_hv code.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-29 00:21:34 +00:00
EXPORT_SYMBOL_GPL ( smp_send_reschedule ) ;
2005-04-16 15:20:36 -07:00
2008-06-26 11:22:13 +02:00
void arch_send_call_function_single_ipi ( int cpu )
{
2014-02-26 05:37:29 +05:30
do_message_pass ( cpu , PPC_MSG_CALL_FUNCTION ) ;
2008-06-26 11:22:13 +02:00
}
2009-09-24 09:34:45 -06:00
void arch_send_call_function_ipi_mask ( const struct cpumask * mask )
2008-06-26 11:22:13 +02:00
{
unsigned int cpu ;
2009-09-24 09:34:45 -06:00
for_each_cpu ( cpu , mask )
2011-05-25 23:34:12 +00:00
do_message_pass ( cpu , PPC_MSG_CALL_FUNCTION ) ;
2008-06-26 11:22:13 +02:00
}
2016-12-20 04:30:08 +10:00
# ifdef CONFIG_NMI_IPI
/*
* " NMI IPI " system .
*
* NMI IPIs may not be recoverable , so should not be used as ongoing part of
* a running system . They can be used for crash , debug , halt / reboot , etc .
*
* The IPI call waits with interrupts disabled until all targets enter the
2018-11-26 12:01:06 +10:00
* NMI handler , then returns . Subsequent IPIs can be issued before targets
* have returned from their handlers , so there is no guarantee about
* concurrency or re - entrancy .
2016-12-20 04:30:08 +10:00
*
2018-11-26 12:01:06 +10:00
* A new NMI can be issued before all targets exit the handler .
2016-12-20 04:30:08 +10:00
*
* The IPI call may time out without all targets entering the NMI handler .
* In that case , there is some logic to recover ( and ignore subsequent
* NMI interrupts that may eventually be raised ) , but the platform interrupt
* handler may not be able to distinguish this from other exception causes ,
* which may cause a crash .
*/
static atomic_t __nmi_ipi_lock = ATOMIC_INIT ( 0 ) ;
static struct cpumask nmi_ipi_pending_mask ;
2018-11-26 12:01:06 +10:00
static bool nmi_ipi_busy = false ;
2016-12-20 04:30:08 +10:00
static void ( * nmi_ipi_function ) ( struct pt_regs * ) = NULL ;
static void nmi_ipi_lock_start ( unsigned long * flags )
{
raw_local_irq_save ( * flags ) ;
hard_irq_disable ( ) ;
while ( atomic_cmpxchg ( & __nmi_ipi_lock , 0 , 1 ) = = 1 ) {
raw_local_irq_restore ( * flags ) ;
2017-08-09 22:41:21 +10:00
spin_until_cond ( atomic_read ( & __nmi_ipi_lock ) = = 0 ) ;
2016-12-20 04:30:08 +10:00
raw_local_irq_save ( * flags ) ;
hard_irq_disable ( ) ;
}
}
static void nmi_ipi_lock ( void )
{
while ( atomic_cmpxchg ( & __nmi_ipi_lock , 0 , 1 ) = = 1 )
2017-08-09 22:41:21 +10:00
spin_until_cond ( atomic_read ( & __nmi_ipi_lock ) = = 0 ) ;
2016-12-20 04:30:08 +10:00
}
static void nmi_ipi_unlock ( void )
{
smp_mb ( ) ;
WARN_ON ( atomic_read ( & __nmi_ipi_lock ) ! = 1 ) ;
atomic_set ( & __nmi_ipi_lock , 0 ) ;
}
static void nmi_ipi_unlock_end ( unsigned long * flags )
{
nmi_ipi_unlock ( ) ;
raw_local_irq_restore ( * flags ) ;
}
/*
* Platform NMI handler calls this to ack
*/
int smp_handle_nmi_ipi ( struct pt_regs * regs )
{
2018-11-26 12:01:06 +10:00
void ( * fn ) ( struct pt_regs * ) = NULL ;
2016-12-20 04:30:08 +10:00
unsigned long flags ;
int me = raw_smp_processor_id ( ) ;
int ret = 0 ;
/*
* Unexpected NMIs are possible here because the interrupt may not
* be able to distinguish NMI IPIs from other types of NMIs , or
* because the caller may have timed out .
*/
nmi_ipi_lock_start ( & flags ) ;
2018-11-26 12:01:06 +10:00
if ( cpumask_test_cpu ( me , & nmi_ipi_pending_mask ) ) {
cpumask_clear_cpu ( me , & nmi_ipi_pending_mask ) ;
fn = READ_ONCE ( nmi_ipi_function ) ;
WARN_ON_ONCE ( ! fn ) ;
ret = 1 ;
}
2016-12-20 04:30:08 +10:00
nmi_ipi_unlock_end ( & flags ) ;
2018-11-26 12:01:06 +10:00
if ( fn )
fn ( regs ) ;
2016-12-20 04:30:08 +10:00
return ret ;
}
2018-05-02 23:07:27 +10:00
static void do_smp_send_nmi_ipi ( int cpu , bool safe )
2016-12-20 04:30:08 +10:00
{
2018-05-02 23:07:27 +10:00
if ( ! safe & & smp_ops - > cause_nmi_ipi & & smp_ops - > cause_nmi_ipi ( cpu ) )
2016-12-20 04:30:09 +10:00
return ;
2016-12-20 04:30:08 +10:00
if ( cpu > = 0 ) {
do_message_pass ( cpu , PPC_MSG_NMI_IPI ) ;
} else {
int c ;
for_each_online_cpu ( c ) {
if ( c = = raw_smp_processor_id ( ) )
continue ;
do_message_pass ( c , PPC_MSG_NMI_IPI ) ;
}
}
}
/*
* - cpu is the target CPU ( must not be this CPU ) , or NMI_IPI_ALL_OTHERS .
* - fn is the target callback function .
* - delay_us > 0 is the delay before giving up waiting for targets to
2018-11-26 12:01:06 +10:00
* begin executing the handler , = = 0 specifies indefinite delay .
2016-12-20 04:30:08 +10:00
*/
2018-11-26 12:01:07 +10:00
static int __smp_send_nmi_ipi ( int cpu , void ( * fn ) ( struct pt_regs * ) ,
u64 delay_us , bool safe )
2016-12-20 04:30:08 +10:00
{
unsigned long flags ;
int me = raw_smp_processor_id ( ) ;
int ret = 1 ;
BUG_ON ( cpu = = me ) ;
BUG_ON ( cpu < 0 & & cpu ! = NMI_IPI_ALL_OTHERS ) ;
if ( unlikely ( ! smp_ops ) )
return 0 ;
nmi_ipi_lock_start ( & flags ) ;
2018-11-26 12:01:06 +10:00
while ( nmi_ipi_busy ) {
2016-12-20 04:30:08 +10:00
nmi_ipi_unlock_end ( & flags ) ;
2018-11-26 12:01:06 +10:00
spin_until_cond ( ! nmi_ipi_busy ) ;
2016-12-20 04:30:08 +10:00
nmi_ipi_lock_start ( & flags ) ;
}
2018-11-26 12:01:06 +10:00
nmi_ipi_busy = true ;
2016-12-20 04:30:08 +10:00
nmi_ipi_function = fn ;
2018-11-26 12:01:06 +10:00
WARN_ON_ONCE ( ! cpumask_empty ( & nmi_ipi_pending_mask ) ) ;
2016-12-20 04:30:08 +10:00
if ( cpu < 0 ) {
/* ALL_OTHERS */
cpumask_copy ( & nmi_ipi_pending_mask , cpu_online_mask ) ;
cpumask_clear_cpu ( me , & nmi_ipi_pending_mask ) ;
} else {
cpumask_set_cpu ( cpu , & nmi_ipi_pending_mask ) ;
}
2018-11-26 12:01:06 +10:00
2016-12-20 04:30:08 +10:00
nmi_ipi_unlock ( ) ;
2018-11-26 12:01:06 +10:00
/* Interrupts remain hard disabled */
2018-05-02 23:07:27 +10:00
do_smp_send_nmi_ipi ( cpu , safe ) ;
2016-12-20 04:30:08 +10:00
2018-04-25 15:17:59 +10:00
nmi_ipi_lock ( ) ;
2018-11-26 12:01:06 +10:00
/* nmi_ipi_busy is set here, so unlock/lock is okay */
2016-12-20 04:30:08 +10:00
while ( ! cpumask_empty ( & nmi_ipi_pending_mask ) ) {
2018-04-25 15:17:59 +10:00
nmi_ipi_unlock ( ) ;
2016-12-20 04:30:08 +10:00
udelay ( 1 ) ;
2018-04-25 15:17:59 +10:00
nmi_ipi_lock ( ) ;
if ( delay_us ) {
delay_us - - ;
if ( ! delay_us )
2018-11-26 12:01:06 +10:00
break ;
2018-04-25 15:17:59 +10:00
}
}
2016-12-20 04:30:08 +10:00
if ( ! cpumask_empty ( & nmi_ipi_pending_mask ) ) {
2018-04-25 15:17:59 +10:00
/* Timeout waiting for CPUs to call smp_handle_nmi_ipi */
2016-12-20 04:30:08 +10:00
ret = 0 ;
cpumask_clear ( & nmi_ipi_pending_mask ) ;
}
2018-04-25 15:17:59 +10:00
2018-11-26 12:01:06 +10:00
nmi_ipi_function = NULL ;
nmi_ipi_busy = false ;
2016-12-20 04:30:08 +10:00
nmi_ipi_unlock_end ( & flags ) ;
return ret ;
}
2018-05-02 23:07:27 +10:00
int smp_send_nmi_ipi ( int cpu , void ( * fn ) ( struct pt_regs * ) , u64 delay_us )
{
return __smp_send_nmi_ipi ( cpu , fn , delay_us , false ) ;
}
int smp_send_safe_nmi_ipi ( int cpu , void ( * fn ) ( struct pt_regs * ) , u64 delay_us )
{
return __smp_send_nmi_ipi ( cpu , fn , delay_us , true ) ;
}
2016-12-20 04:30:08 +10:00
# endif /* CONFIG_NMI_IPI */
2014-02-26 05:37:43 +05:30
# ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
void tick_broadcast ( const struct cpumask * mask )
{
unsigned int cpu ;
for_each_cpu ( cpu , mask )
do_message_pass ( cpu , PPC_MSG_TICK_BROADCAST ) ;
}
# endif
2016-12-20 04:30:08 +10:00
# ifdef CONFIG_DEBUGGER
2021-01-04 15:31:52 +01:00
static void debugger_ipi_callback ( struct pt_regs * regs )
2005-04-16 15:20:36 -07:00
{
2016-12-20 04:30:08 +10:00
debugger_ipi ( regs ) ;
}
2011-05-10 19:29:06 +00:00
2016-12-20 04:30:08 +10:00
void smp_send_debugger_break ( void )
{
smp_send_nmi_ipi ( NMI_IPI_ALL_OTHERS , debugger_ipi_callback , 1000000 ) ;
2005-04-16 15:20:36 -07:00
}
# endif
2016-11-29 23:45:50 +11:00
# ifdef CONFIG_KEXEC_CORE
2005-12-04 18:39:43 +11:00
void crash_send_ipi ( void ( * crash_ipi_callback ) ( struct pt_regs * ) )
{
2017-12-15 19:14:55 +11:00
int cpu ;
2016-12-20 04:30:08 +10:00
smp_send_nmi_ipi ( NMI_IPI_ALL_OTHERS , crash_ipi_callback , 1000000 ) ;
2017-12-15 19:14:55 +11:00
if ( kdump_in_progress ( ) & & crash_wake_offline ) {
for_each_present_cpu ( cpu ) {
if ( cpu_online ( cpu ) )
continue ;
/*
* crash_ipi_callback will wait for
* all cpus , including offline CPUs .
* We don ' t care about nmi_ipi_function .
* Offline cpus will jump straight into
* crash_ipi_callback , we can skip the
* entire NMI dance and waiting for
* cpus to clear pending mask , etc .
*/
2018-05-02 23:07:27 +10:00
do_smp_send_nmi_ipi ( cpu , false ) ;
2017-12-15 19:14:55 +11:00
}
}
2005-12-04 18:39:43 +11:00
}
# endif
2018-04-25 12:17:53 +10:00
# ifdef CONFIG_NMI_IPI
static void nmi_stop_this_cpu ( struct pt_regs * regs )
{
/*
2018-04-27 11:51:59 +10:00
* IRQs are already hard disabled by the smp_handle_nmi_ipi .
2018-04-25 12:17:53 +10:00
*/
2021-06-23 14:12:45 +10:00
set_cpu_online ( smp_processor_id ( ) , false ) ;
2018-04-27 11:51:59 +10:00
spin_begin ( ) ;
while ( 1 )
spin_cpu_relax ( ) ;
2018-04-25 12:17:53 +10:00
}
2007-09-18 09:43:40 +10:00
void smp_send_stop ( void )
{
2018-04-25 12:17:53 +10:00
smp_send_nmi_ipi ( NMI_IPI_ALL_OTHERS , nmi_stop_this_cpu , 1000000 ) ;
2018-04-27 11:51:59 +10:00
}
# else /* CONFIG_NMI_IPI */
static void stop_this_cpu ( void * dummy )
{
hard_irq_disable ( ) ;
2021-06-23 14:12:45 +10:00
/*
* Offlining CPUs in stop_this_cpu can result in scheduler warnings ,
* ( see commit de6e5d38417e ) , but printk_safe_flush_on_panic ( ) wants
* to know other CPUs are offline before it breaks locks to flush
* printk buffers , in case we panic ( ) ed while holding the lock .
*/
set_cpu_online ( smp_processor_id ( ) , false ) ;
2018-04-27 11:51:59 +10:00
spin_begin ( ) ;
while ( 1 )
spin_cpu_relax ( ) ;
}
void smp_send_stop ( void )
{
static bool stopped = false ;
/*
* Prevent waiting on csd lock from a previous smp_send_stop .
* This is racy , but in general callers try to do the right
* thing and only fire off one smp_send_stop ( e . g . , see
* kernel / panic . c )
*/
if ( stopped )
return ;
stopped = true ;
2008-06-06 11:18:06 +02:00
smp_call_function ( stop_this_cpu , NULL , 0 ) ;
2005-04-16 15:20:36 -07:00
}
2018-04-27 11:51:59 +10:00
# endif /* CONFIG_NMI_IPI */
2005-04-16 15:20:36 -07:00
2019-01-31 10:09:02 +00:00
struct task_struct * current_set [ NR_CPUS ] ;
2005-04-16 15:20:36 -07:00
2012-12-21 14:04:10 -08:00
static void smp_store_cpu_info ( int id )
2005-04-16 15:20:36 -07:00
{
2009-10-29 22:34:14 +09:00
per_cpu ( cpu_pvr , id ) = mfspr ( SPRN_PVR ) ;
2011-06-28 14:54:47 -05:00
# ifdef CONFIG_PPC_FSL_BOOK3E
per_cpu ( next_tlbcam_idx , id )
= ( mfspr ( SPRN_TLB1CFG ) & TLBnCFG_N_ENTRY ) - 1 ;
# endif
2005-04-16 15:20:36 -07:00
}
2017-06-29 17:12:54 +10:00
/*
* Relationships between CPUs are maintained in a set of per - cpu cpumasks so
* rather than just passing around the cpumask we pass around a function that
* returns the that cpumask for the given CPU .
*/
static void set_cpus_related ( int i , int j , struct cpumask * ( * get_cpumask ) ( int ) )
{
cpumask_set_cpu ( i , get_cpumask ( j ) ) ;
cpumask_set_cpu ( j , get_cpumask ( i ) ) ;
}
# ifdef CONFIG_HOTPLUG_CPU
static void set_cpus_unrelated ( int i , int j ,
struct cpumask * ( * get_cpumask ) ( int ) )
{
cpumask_clear_cpu ( i , get_cpumask ( j ) ) ;
cpumask_clear_cpu ( j , get_cpumask ( i ) ) ;
}
# endif
2020-09-21 15:26:51 +05:30
/*
* Extends set_cpus_related . Instead of setting one CPU at a time in
* dstmask , set srcmask at oneshot . dstmask should be super set of srcmask .
*/
static void or_cpumasks_related ( int i , int j , struct cpumask * ( * srcmask ) ( int ) ,
struct cpumask * ( * dstmask ) ( int ) )
{
struct cpumask * mask ;
int k ;
mask = srcmask ( j ) ;
for_each_cpu ( k , srcmask ( i ) )
cpumask_or ( dstmask ( k ) , dstmask ( k ) , mask ) ;
if ( i = = j )
return ;
mask = srcmask ( i ) ;
for_each_cpu ( k , srcmask ( j ) )
cpumask_or ( dstmask ( k ) , dstmask ( k ) , mask ) ;
}
2018-10-11 11:03:01 +05:30
/*
* parse_thread_groups : Parses the " ibm,thread-groups " device tree
* property for the CPU device node @ dn and stores
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
* the parsed output in the thread_groups_list
* structure @ tglp .
2018-10-11 11:03:01 +05:30
*
* @ dn : The device node of the CPU device .
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
* @ tglp : Pointer to a thread group list structure into which the parsed
2018-10-11 11:03:01 +05:30
* output of " ibm,thread-groups " is stored .
*
* ibm , thread - groups [ 0. . N - 1 ] array defines which group of threads in
* the CPU - device node can be grouped together based on the property .
*
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
* This array can represent thread groupings for multiple properties .
*
* ibm , thread - groups [ i + 0 ] tells us the property based on which the
2018-10-11 11:03:01 +05:30
* threads are being grouped together . If this value is 1 , it implies
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
* that the threads in the same group share L1 , translation cache . If
* the value is 2 , it implies that the threads in the same group share
* the same L2 cache .
2018-10-11 11:03:01 +05:30
*
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
* ibm , thread - groups [ i + 1 ] tells us how many such thread groups exist for the
* property ibm , thread - groups [ i ]
2018-10-11 11:03:01 +05:30
*
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
* ibm , thread - groups [ i + 2 ] tells us the number of threads in each such
2018-10-11 11:03:01 +05:30
* group .
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
* Suppose k = ( ibm , thread - groups [ i + 1 ] * ibm , thread - groups [ i + 2 ] ) , then ,
2018-10-11 11:03:01 +05:30
*
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
* ibm , thread - groups [ i + 3. . i + k + 2 ] ( is the list of threads identified by
2018-10-11 11:03:01 +05:30
* " ibm,ppc-interrupt-server#s " arranged as per their membership in
* the grouping .
*
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
* Example :
* If " ibm,thread-groups " = [ 1 , 2 , 4 , 8 , 10 , 12 , 14 , 9 , 11 , 13 , 15 , 2 , 2 , 4 , 8 , 10 , 12 , 14 , 9 , 11 , 13 , 15 ]
* This can be decomposed up into two consecutive arrays :
* a ) [ 1 , 2 , 4 , 8 , 10 , 12 , 14 , 9 , 11 , 13 , 15 ]
* b ) [ 2 , 2 , 4 , 8 , 10 , 12 , 14 , 9 , 11 , 13 , 15 ]
*
* where in ,
*
* a ) provides information of Property " 1 " being shared by " 2 " groups ,
* each with " 4 " threads each . The " ibm,ppc-interrupt-server#s " of
* the first group is { 8 , 10 , 12 , 14 } and the
* " ibm,ppc-interrupt-server#s " of the second group is
* { 9 , 11 , 13 , 15 } . Property " 1 " is indicative of the thread in the
* group sharing L1 cache , translation cache and Instruction Data
* flow .
2018-10-11 11:03:01 +05:30
*
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
* b ) provides information of Property " 2 " being shared by " 2 " groups ,
* each group with " 4 " threads . The " ibm,ppc-interrupt-server#s " of
* the first group is { 8 , 10 , 12 , 14 } and the
* " ibm,ppc-interrupt-server#s " of the second group is
* { 9 , 11 , 13 , 15 } . Property " 2 " indicates that the threads in each
* group share the L2 - cache .
2018-10-11 11:03:01 +05:30
*
* Returns 0 on success , - EINVAL if the property does not exist ,
* - ENODATA if property does not have a value , and - EOVERFLOW if the
* property data isn ' t large enough .
*/
static int parse_thread_groups ( struct device_node * dn ,
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
struct thread_groups_list * tglp )
2018-10-11 11:03:01 +05:30
{
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
unsigned int property_idx = 0 ;
u32 * thread_group_array ;
2018-10-11 11:03:01 +05:30
size_t total_threads ;
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
int ret = 0 , count ;
u32 * thread_list ;
int i = 0 ;
2018-10-11 11:03:01 +05:30
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
count = of_property_count_u32_elems ( dn , " ibm,thread-groups " ) ;
thread_group_array = kcalloc ( count , sizeof ( u32 ) , GFP_KERNEL ) ;
2018-10-11 11:03:01 +05:30
ret = of_property_read_u32_array ( dn , " ibm,thread-groups " ,
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
thread_group_array , count ) ;
2018-10-11 11:03:01 +05:30
if ( ret )
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
goto out_free ;
2018-10-11 11:03:01 +05:30
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
while ( i < count & & property_idx < MAX_THREAD_GROUP_PROPERTIES ) {
int j ;
struct thread_groups * tg = & tglp - > property_tgs [ property_idx + + ] ;
2018-10-11 11:03:01 +05:30
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
tg - > property = thread_group_array [ i ] ;
tg - > nr_groups = thread_group_array [ i + 1 ] ;
tg - > threads_per_group = thread_group_array [ i + 2 ] ;
total_threads = tg - > nr_groups * tg - > threads_per_group ;
2018-10-11 11:03:01 +05:30
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
thread_list = & thread_group_array [ i + 3 ] ;
2018-10-11 11:03:01 +05:30
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
for ( j = 0 ; j < total_threads ; j + + )
tg - > thread_list [ j ] = thread_list [ j ] ;
i = i + 3 + total_threads ;
}
2018-10-11 11:03:01 +05:30
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
tglp - > nr_properties = property_idx ;
out_free :
kfree ( thread_group_array ) ;
return ret ;
2018-10-11 11:03:01 +05:30
}
/*
* get_cpu_thread_group_start : Searches the thread group in tg - > thread_list
* that @ cpu belongs to .
*
* @ cpu : The logical CPU whose thread group is being searched .
* @ tg : The thread - group structure of the CPU node which @ cpu belongs
* to .
*
* Returns the index to tg - > thread_list that points to the the start
* of the thread_group that @ cpu belongs to .
*
* Returns - 1 if cpu doesn ' t belong to any of the groups pointed to by
* tg - > thread_list .
*/
static int get_cpu_thread_group_start ( int cpu , struct thread_groups * tg )
{
int hw_cpu_id = get_hard_smp_processor_id ( cpu ) ;
int i , j ;
for ( i = 0 ; i < tg - > nr_groups ; i + + ) {
int group_start = i * tg - > threads_per_group ;
for ( j = 0 ; j < tg - > threads_per_group ; j + + ) {
int idx = group_start + j ;
if ( tg - > thread_list [ idx ] = = hw_cpu_id )
return group_start ;
}
}
return - 1 ;
}
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
static struct thread_groups * __init get_thread_groups ( int cpu ,
int group_property ,
int * err )
{
struct device_node * dn = of_get_cpu_node ( cpu , NULL ) ;
struct thread_groups_list * cpu_tgl = & tgl [ cpu ] ;
struct thread_groups * tg = NULL ;
int i ;
* err = 0 ;
if ( ! dn ) {
* err = - ENODATA ;
return NULL ;
}
if ( ! cpu_tgl - > nr_properties ) {
* err = parse_thread_groups ( dn , cpu_tgl ) ;
if ( * err )
goto out ;
}
for ( i = 0 ; i < cpu_tgl - > nr_properties ; i + + ) {
if ( cpu_tgl - > property_tgs [ i ] . property = = group_property ) {
tg = & cpu_tgl - > property_tgs [ i ] ;
break ;
}
}
if ( ! tg )
* err = - EINVAL ;
out :
of_node_put ( dn ) ;
return tg ;
}
2021-07-28 23:26:07 +05:30
static int update_mask_from_threadgroup ( cpumask_var_t * mask , struct thread_groups * tg , int cpu , int cpu_group_start )
{
int first_thread = cpu_first_thread_sibling ( cpu ) ;
int i ;
zalloc_cpumask_var_node ( mask , GFP_KERNEL , cpu_to_node ( cpu ) ) ;
for ( i = first_thread ; i < first_thread + threads_per_core ; i + + ) {
int i_group_start = get_cpu_thread_group_start ( i , tg ) ;
if ( unlikely ( i_group_start = = - 1 ) ) {
WARN_ON_ONCE ( 1 ) ;
return - ENODATA ;
}
if ( i_group_start = = cpu_group_start )
cpumask_set_cpu ( i , * mask ) ;
}
return 0 ;
}
2020-12-10 16:08:57 +05:30
static int __init init_thread_group_cache_map ( int cpu , int cache_property )
2018-10-11 11:03:01 +05:30
{
2021-07-28 23:26:07 +05:30
int cpu_group_start = - 1 , err = 0 ;
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
struct thread_groups * tg = NULL ;
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
cpumask_var_t * mask = NULL ;
2018-10-11 11:03:01 +05:30
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
if ( cache_property ! = THREAD_GROUP_SHARE_L1 & &
2021-07-28 23:26:07 +05:30
cache_property ! = THREAD_GROUP_SHARE_L2_L3 )
2020-12-10 16:08:57 +05:30
return - EINVAL ;
tg = get_thread_groups ( cpu , cache_property , & err ) ;
2021-07-28 23:26:07 +05:30
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
if ( ! tg )
return err ;
2018-10-11 11:03:01 +05:30
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
cpu_group_start = get_cpu_thread_group_start ( cpu , tg ) ;
2018-10-11 11:03:01 +05:30
if ( unlikely ( cpu_group_start = = - 1 ) ) {
WARN_ON_ONCE ( 1 ) ;
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
return - ENODATA ;
2018-10-11 11:03:01 +05:30
}
2021-07-28 23:26:07 +05:30
if ( cache_property = = THREAD_GROUP_SHARE_L1 ) {
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
mask = & per_cpu ( thread_group_l1_cache_map , cpu ) ;
2021-07-28 23:26:07 +05:30
update_mask_from_threadgroup ( mask , tg , cpu , cpu_group_start ) ;
}
else if ( cache_property = = THREAD_GROUP_SHARE_L2_L3 ) {
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
mask = & per_cpu ( thread_group_l2_cache_map , cpu ) ;
2021-07-28 23:26:07 +05:30
update_mask_from_threadgroup ( mask , tg , cpu , cpu_group_start ) ;
mask = & per_cpu ( thread_group_l3_cache_map , cpu ) ;
update_mask_from_threadgroup ( mask , tg , cpu , cpu_group_start ) ;
2018-10-11 11:03:01 +05:30
}
2021-07-28 23:26:07 +05:30
powerpc/smp: Parse ibm,thread-groups with multiple properties
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:55 +05:30
return 0 ;
2018-10-11 11:03:01 +05:30
}
2020-08-10 12:48:27 +05:30
static bool shared_caches ;
# ifdef CONFIG_SCHED_SMT
/* cpumask of CPUs with asymmetric SMT dependency */
static int powerpc_smt_flags ( void )
{
int flags = SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES ;
if ( cpu_has_feature ( CPU_FTR_ASYM_SMT ) ) {
printk_once ( KERN_INFO " Enabling Asymmetric SMT scheduling \n " ) ;
flags | = SD_ASYM_PACKING ;
}
return flags ;
}
# endif
/*
* P9 has a slightly odd architecture where pairs of cores share an L2 cache .
* This topology makes it * much * cheaper to migrate tasks between adjacent cores
* since the migrated task remains cache hot . We want to take advantage of this
* at the scheduler level so an extra topology level is required .
*/
static int powerpc_shared_cache_flags ( void )
{
return SD_SHARE_PKG_RESOURCES ;
}
/*
* We can ' t just pass cpu_l2_cache_mask ( ) directly because
* returns a non - const pointer and the compiler barfs on that .
*/
static const struct cpumask * shared_cache_mask ( int cpu )
{
2020-08-10 12:48:30 +05:30
return per_cpu ( cpu_l2_cache_map , cpu ) ;
2020-08-10 12:48:27 +05:30
}
# ifdef CONFIG_SCHED_SMT
static const struct cpumask * smallcore_smt_mask ( int cpu )
{
return cpu_smallcore_mask ( cpu ) ;
}
# endif
2020-08-10 12:48:33 +05:30
static struct cpumask * cpu_coregroup_mask ( int cpu )
{
return per_cpu ( cpu_coregroup_map , cpu ) ;
}
static bool has_coregroup_support ( void )
{
return coregroup_enabled ;
}
static const struct cpumask * cpu_mc_mask ( int cpu )
{
return cpu_coregroup_mask ( cpu ) ;
}
2020-08-10 12:48:27 +05:30
static struct sched_domain_topology_level powerpc_topology [ ] = {
# ifdef CONFIG_SCHED_SMT
{ cpu_smt_mask , powerpc_smt_flags , SD_INIT_NAME ( SMT ) } ,
# endif
{ shared_cache_mask , powerpc_shared_cache_flags , SD_INIT_NAME ( CACHE ) } ,
2020-08-10 12:48:33 +05:30
{ cpu_mc_mask , SD_INIT_NAME ( MC ) } ,
2020-08-10 12:48:27 +05:30
{ cpu_cpu_mask , SD_INIT_NAME ( DIE ) } ,
{ NULL , } ,
} ;
2020-12-21 08:41:54 +01:00
static int __init init_big_cores ( void )
2018-10-11 11:03:01 +05:30
{
int cpu ;
for_each_possible_cpu ( cpu ) {
2020-12-10 16:08:57 +05:30
int err = init_thread_group_cache_map ( cpu , THREAD_GROUP_SHARE_L1 ) ;
2018-10-11 11:03:01 +05:30
if ( err )
return err ;
zalloc_cpumask_var_node ( & per_cpu ( cpu_smallcore_map , cpu ) ,
GFP_KERNEL ,
cpu_to_node ( cpu ) ) ;
}
has_big_cores = true ;
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
for_each_possible_cpu ( cpu ) {
2021-07-28 23:26:07 +05:30
int err = init_thread_group_cache_map ( cpu , THREAD_GROUP_SHARE_L2_L3 ) ;
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
if ( err )
return err ;
}
thread_group_shares_l2 = true ;
2021-07-28 23:26:07 +05:30
thread_group_shares_l3 = true ;
pr_debug ( " L2/L3 cache only shared by the threads in the small core \n " ) ;
2018-10-11 11:03:01 +05:30
return 0 ;
}
2005-04-16 15:20:36 -07:00
void __init smp_prepare_cpus ( unsigned int max_cpus )
{
unsigned int cpu ;
DBG ( " smp_prepare_cpus \n " ) ;
/*
* setup_cpu may need to be called on the boot cpu . We havent
* spun any cpus up but lets be paranoid .
*/
BUG_ON ( boot_cpuid ! = smp_processor_id ( ) ) ;
/* Fixup boot cpu */
smp_store_cpu_info ( boot_cpuid ) ;
cpu_callin_map [ boot_cpuid ] = 1 ;
2010-04-26 15:32:41 +00:00
for_each_possible_cpu ( cpu ) {
zalloc_cpumask_var_node ( & per_cpu ( cpu_sibling_map , cpu ) ,
GFP_KERNEL , cpu_to_node ( cpu ) ) ;
2017-06-29 17:12:55 +10:00
zalloc_cpumask_var_node ( & per_cpu ( cpu_l2_cache_map , cpu ) ,
GFP_KERNEL , cpu_to_node ( cpu ) ) ;
2010-04-26 15:32:41 +00:00
zalloc_cpumask_var_node ( & per_cpu ( cpu_core_map , cpu ) ,
GFP_KERNEL , cpu_to_node ( cpu ) ) ;
2020-08-10 12:48:33 +05:30
if ( has_coregroup_support ( ) )
zalloc_cpumask_var_node ( & per_cpu ( cpu_coregroup_map , cpu ) ,
GFP_KERNEL , cpu_to_node ( cpu ) ) ;
2021-06-28 19:43:01 -07:00
# ifdef CONFIG_NUMA
powerpc: reorder per-cpu NUMA information's initialization
There is an issue currently where NUMA information is used on powerpc
(and possibly ia64) before it has been read from the device-tree, which
leads to large slab consumption with CONFIG_SLUB and memoryless nodes.
NUMA powerpc non-boot CPU's cpu_to_node/cpu_to_mem is only accurate
after start_secondary(), similar to ia64, which is invoked via
smp_init().
Commit 6ee0578b4daae ("workqueue: mark init_workqueues() as
early_initcall()") made init_workqueues() be invoked via
do_pre_smp_initcalls(), which is obviously before the secondary
processors are online.
Additionally, the following commits changed init_workqueues() to use
cpu_to_node to determine the node to use for kthread_create_on_node:
bce903809ab3f ("workqueue: add wq_numa_tbl_len and
wq_numa_possible_cpumask[]")
f3f90ad469342 ("workqueue: determine NUMA node of workers accourding to
the allowed cpumask")
Therefore, when init_workqueues() runs, it sees all CPUs as being on
Node 0. On LPARs or KVM guests where Node 0 is memoryless, this leads to
a high number of slab deactivations
(http://www.spinics.net/lists/linux-mm/msg67489.html).
Fix this by initializing the powerpc-specific CPU<->node/local memory
node mapping as early as possible, which on powerpc is
do_init_bootmem(). Currently that function initializes the mapping for
the boot CPU, but we extend it to setup the mapping for all possible
CPUs. Then, in smp_prepare_cpus(), we can correspondingly set the
per-cpu values for all possible CPUs. That ensures that before the
early_initcalls run (and really as early as possible), the per-cpu NUMA
mapping is accurate.
While testing memoryless nodes on PowerKVM guests with a fix to the
workqueue logic to use cpu_to_mem() instead of cpu_to_node(), with a
guest topology of:
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus: 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
node 1 size: 16336 MB
node 1 free: 15329 MB
node distances:
node 0 1
0: 10 40
1: 40 10
the slab consumption decreases from
Slab: 932416 kB
SUnreclaim: 902336 kB
to
Slab: 395264 kB
SUnreclaim: 359424 kB
And we a corresponding increase in the slab efficiency from
slab mem objs slabs
used active active
------------------------------------------------------------
kmalloc-16384 337 MB 11.28% 100.00%
task_struct 288 MB 9.93% 100.00%
to
slab mem objs slabs
used active active
------------------------------------------------------------
kmalloc-16384 37 MB 100.00% 100.00%
task_struct 31 MB 100.00% 100.00%
Powerpc didn't support memoryless nodes until recently (64bb80d87f01
"powerpc/numa: Enable CONFIG_HAVE_MEMORYLESS_NODES" and 8c272261194d
"powerpc/numa: Enable USE_PERCPU_NUMA_NODE_ID"). Those commits also
helped improve memory consumption with these kind of environments.
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-07-17 16:15:12 -07:00
/*
* numa_node_id ( ) works after this .
*/
2014-08-27 17:34:00 +08:00
if ( cpu_present ( cpu ) ) {
set_cpu_numa_node ( cpu , numa_cpu_lookup_table [ cpu ] ) ;
set_cpu_numa_mem ( cpu ,
local_memory_node ( numa_cpu_lookup_table [ cpu ] ) ) ;
}
2020-08-10 12:48:25 +05:30
# endif
2010-04-26 15:32:41 +00:00
}
2017-06-29 17:12:54 +10:00
/* Init the cpumasks so the boot CPU is related to itself */
2010-04-26 15:32:41 +00:00
cpumask_set_cpu ( boot_cpuid , cpu_sibling_mask ( boot_cpuid ) ) ;
2017-06-29 17:12:55 +10:00
cpumask_set_cpu ( boot_cpuid , cpu_l2_cache_mask ( boot_cpuid ) ) ;
2021-04-15 17:39:32 +05:30
cpumask_set_cpu ( boot_cpuid , cpu_core_mask ( boot_cpuid ) ) ;
2010-04-26 15:32:41 +00:00
2020-08-10 12:48:33 +05:30
if ( has_coregroup_support ( ) )
cpumask_set_cpu ( boot_cpuid , cpu_coregroup_mask ( boot_cpuid ) ) ;
2018-10-11 11:03:01 +05:30
init_big_cores ( ) ;
if ( has_big_cores ) {
cpumask_set_cpu ( boot_cpuid ,
cpu_smallcore_mask ( boot_cpuid ) ) ;
}
2021-04-15 17:39:34 +05:30
if ( cpu_to_chip_id ( boot_cpuid ) ! = - 1 ) {
2021-08-26 15:33:59 +05:30
int idx = DIV_ROUND_UP ( num_possible_cpus ( ) , threads_per_core ) ;
2021-04-15 17:39:34 +05:30
/*
* All threads of a core will all belong to the same core ,
* chip_id_lookup_table will have one entry per core .
* Assumption : if boot_cpuid doesn ' t have a chip - id , then no
* other CPUs , will also not have chip - id .
*/
chip_id_lookup_table = kcalloc ( idx , sizeof ( int ) , GFP_KERNEL ) ;
if ( chip_id_lookup_table )
memset ( chip_id_lookup_table , - 1 , sizeof ( int ) * idx ) ;
}
2013-07-22 14:40:20 +08:00
if ( smp_ops & & smp_ops - > probe )
smp_ops - > probe ( ) ;
2005-04-16 15:20:36 -07:00
}
2012-12-21 14:04:10 -08:00
void smp_prepare_boot_cpu ( void )
2005-04-16 15:20:36 -07:00
{
BUG_ON ( smp_processor_id ( ) ! = boot_cpuid ) ;
2005-11-05 10:33:55 +11:00
# ifdef CONFIG_PPC64
2018-02-14 01:08:12 +10:00
paca_ptrs [ boot_cpuid ] - > __current = current ;
2005-11-05 10:33:55 +11:00
# endif
2014-05-19 11:14:23 -07:00
set_numa_node ( numa_cpu_lookup_table [ boot_cpuid ] ) ;
2019-01-31 10:09:02 +00:00
current_set [ boot_cpuid ] = current ;
2005-04-16 15:20:36 -07:00
}
# ifdef CONFIG_HOTPLUG_CPU
int generic_cpu_disable ( void )
{
unsigned int cpu = smp_processor_id ( ) ;
if ( cpu = = boot_cpuid )
return - EBUSY ;
2009-09-24 09:34:48 -06:00
set_cpu_online ( cpu , false ) ;
2005-11-10 13:37:51 +11:00
# ifdef CONFIG_PPC64
2005-11-11 21:15:21 +11:00
vdso_data - > processorCount - - ;
2005-11-10 14:26:12 +11:00
# endif
2017-04-05 17:54:49 +10:00
/* Update affinity of all IRQs previously aimed at this CPU */
irq_migrate_all_off_this_cpu ( ) ;
2017-02-15 20:49:54 +11:00
/*
* Depending on the details of the interrupt controller , it ' s possible
* that one of the interrupts we just migrated away from this CPU is
* actually already pending on this CPU . If we leave it in that state
* the interrupt will never be EOI ' ed , and will never fire again . So
* temporarily enable interrupts here , to allow any pending interrupt to
* be received ( and EOI ' ed ) , before we take this CPU offline .
*/
2017-04-05 17:54:49 +10:00
local_irq_enable ( ) ;
mdelay ( 1 ) ;
local_irq_disable ( ) ;
2005-04-16 15:20:36 -07:00
return 0 ;
}
void generic_cpu_die ( unsigned int cpu )
{
int i ;
for ( i = 0 ; i < 100 ; i + + ) {
2005-05-01 08:58:47 -07:00
smp_rmb ( ) ;
2015-11-20 17:14:01 +08:00
if ( is_cpu_dead ( cpu ) )
2005-04-16 15:20:36 -07:00
return ;
msleep ( 100 ) ;
}
printk ( KERN_ERR " CPU%d didn't die... \n " , cpu ) ;
}
2011-04-01 09:23:37 +11:00
void generic_set_cpu_dead ( unsigned int cpu )
{
per_cpu ( cpu_state , cpu ) = CPU_DEAD ;
}
2011-09-19 17:44:49 +00:00
2012-07-20 20:42:34 +08:00
/*
* The cpu_state should be set to CPU_UP_PREPARE in kick_cpu ( ) , otherwise
* the cpu_state is always CPU_DEAD after calling generic_set_cpu_dead ( ) ,
* which makes the delay in generic_cpu_die ( ) not happen .
*/
void generic_set_cpu_up ( unsigned int cpu )
{
per_cpu ( cpu_state , cpu ) = CPU_UP_PREPARE ;
}
2011-09-19 17:44:49 +00:00
int generic_check_cpu_restart ( unsigned int cpu )
{
return per_cpu ( cpu_state , cpu ) = = CPU_UP_PREPARE ;
}
2012-10-15 01:15:41 +00:00
2015-11-20 17:14:01 +08:00
int is_cpu_dead ( unsigned int cpu )
{
return per_cpu ( cpu_state , cpu ) = = CPU_DEAD ;
}
2014-05-23 18:15:25 +10:00
static bool secondaries_inhibited ( void )
2012-10-15 01:15:41 +00:00
{
2014-05-23 18:15:25 +10:00
return kvm_hv_mode_active ( ) ;
2012-10-15 01:15:41 +00:00
}
# else /* HOTPLUG_CPU */
# define secondaries_inhibited() 0
2005-04-16 15:20:36 -07:00
# endif
2012-04-20 13:05:48 +00:00
static void cpu_idle_thread_init ( unsigned int cpu , struct task_struct * idle )
2011-03-08 14:40:04 +11:00
{
# ifdef CONFIG_PPC64
2018-02-14 01:08:12 +10:00
paca_ptrs [ cpu ] - > __current = idle ;
2019-01-17 23:26:56 +11:00
paca_ptrs [ cpu ] - > kstack = ( unsigned long ) task_stack_page ( idle ) +
THREAD_SIZE - STACK_FRAME_OVERHEAD ;
2011-03-08 14:40:04 +11:00
# endif
2019-01-31 10:08:58 +00:00
idle - > cpu = cpu ;
2019-01-31 10:09:02 +00:00
secondary_current = current_set [ cpu ] = idle ;
2011-03-08 14:40:04 +11:00
}
2013-06-24 15:30:09 -04:00
int __cpu_up ( unsigned int cpu , struct task_struct * tidle )
2005-04-16 15:20:36 -07:00
{
2011-03-08 14:40:04 +11:00
int rc , c ;
2005-04-16 15:20:36 -07:00
2012-10-15 01:15:41 +00:00
/*
* Don ' t allow secondary threads to come online if inhibited
*/
if ( threads_per_core > 1 & & secondaries_inhibited ( ) & &
2014-05-23 18:15:28 +10:00
cpu_thread_in_subcore ( cpu ) )
2012-10-15 01:15:41 +00:00
return - EBUSY ;
2006-07-04 14:09:36 +10:00
if ( smp_ops = = NULL | |
( smp_ops - > cpu_bootable & & ! smp_ops - > cpu_bootable ( cpu ) ) )
2005-04-16 15:20:36 -07:00
return - EINVAL ;
2012-04-20 13:05:48 +00:00
cpu_idle_thread_init ( cpu , tidle ) ;
2011-05-17 23:57:11 +00:00
2017-04-05 17:54:48 +10:00
/*
* The platform might need to allocate resources prior to bringing
* up the CPU
*/
if ( smp_ops - > prepare_cpu ) {
rc = smp_ops - > prepare_cpu ( cpu ) ;
if ( rc )
return rc ;
}
2005-04-16 15:20:36 -07:00
/* Make sure callin-map entry is 0 (can be leftover a CPU
* hotplug
*/
cpu_callin_map [ cpu ] = 0 ;
/* The information for processor bringup must
* be written out to main store before we release
* the processor .
*/
2005-05-01 08:58:47 -07:00
smp_mb ( ) ;
2005-04-16 15:20:36 -07:00
/* wake up cpus */
DBG ( " smp: kicking cpu %d \n " , cpu ) ;
2011-04-11 21:46:19 +00:00
rc = smp_ops - > kick_cpu ( cpu ) ;
if ( rc ) {
pr_err ( " smp: failed starting cpu %d (rc %d) \n " , cpu , rc ) ;
return rc ;
}
2005-04-16 15:20:36 -07:00
/*
* wait to see if the cpu made a callin ( is actually up ) .
* use this value that I found through experimentation .
* - - Cort
*/
if ( system_state < SYSTEM_RUNNING )
2006-06-17 17:52:44 -05:00
for ( c = 50000 ; c & & ! cpu_callin_map [ cpu ] ; c - - )
2005-04-16 15:20:36 -07:00
udelay ( 100 ) ;
# ifdef CONFIG_HOTPLUG_CPU
else
/*
* CPUs can take much longer to come up in the
* hotplug case . Wait five seconds .
*/
2009-06-23 23:26:37 +00:00
for ( c = 5000 ; c & & ! cpu_callin_map [ cpu ] ; c - - )
msleep ( 1 ) ;
2005-04-16 15:20:36 -07:00
# endif
if ( ! cpu_callin_map [ cpu ] ) {
2010-08-04 18:28:34 +00:00
printk ( KERN_ERR " Processor %u is stuck. \n " , cpu ) ;
2005-04-16 15:20:36 -07:00
return - ENOENT ;
}
2010-08-04 18:28:34 +00:00
DBG ( " Processor %u found. \n " , cpu ) ;
2005-04-16 15:20:36 -07:00
if ( smp_ops - > give_timebase )
smp_ops - > give_timebase ( ) ;
2015-02-24 17:58:02 +11:00
/* Wait until cpu puts itself in the online & active maps */
2017-06-06 23:08:32 +10:00
spin_until_cond ( cpu_online ( cpu ) ) ;
2005-04-16 15:20:36 -07:00
return 0 ;
}
2008-07-27 15:24:54 +10:00
/* Return the value of the reg property corresponding to the given
* logical cpu .
*/
int cpu_to_core_id ( int cpu )
{
struct device_node * np ;
2013-12-12 15:59:36 +11:00
const __be32 * reg ;
2008-07-27 15:24:54 +10:00
int id = - 1 ;
np = of_get_cpu_node ( cpu , NULL ) ;
if ( ! np )
goto out ;
reg = of_get_property ( np , " reg " , NULL ) ;
if ( ! reg )
goto out ;
2013-12-12 15:59:36 +11:00
id = be32_to_cpup ( reg ) ;
2008-07-27 15:24:54 +10:00
out :
of_node_put ( np ) ;
return id ;
}
2016-06-02 08:45:14 -03:00
EXPORT_SYMBOL_GPL ( cpu_to_core_id ) ;
2008-07-27 15:24:54 +10:00
2010-10-06 08:36:59 +00:00
/* Helper routines for cpu to core mapping */
int cpu_core_index_of_thread ( int cpu )
{
return cpu > > threads_shift ;
}
EXPORT_SYMBOL_GPL ( cpu_core_index_of_thread ) ;
int cpu_first_thread_of_core ( int core )
{
return core < < threads_shift ;
}
EXPORT_SYMBOL_GPL ( cpu_first_thread_of_core ) ;
2011-04-28 05:07:23 +00:00
/* Must be called when no change can occur to cpu_present_mask,
2008-07-27 15:24:53 +10:00
* i . e . during cpu online or offline .
*/
static struct device_node * cpu_to_l2cache ( int cpu )
{
struct device_node * np ;
2008-12-10 20:16:07 +00:00
struct device_node * cache ;
2008-07-27 15:24:53 +10:00
if ( ! cpu_present ( cpu ) )
return NULL ;
np = of_get_cpu_node ( cpu , NULL ) ;
if ( np = = NULL )
return NULL ;
2008-12-10 20:16:07 +00:00
cache = of_find_next_cache_node ( np ) ;
2008-07-27 15:24:53 +10:00
of_node_put ( np ) ;
2008-12-10 20:16:07 +00:00
return cache ;
2008-07-27 15:24:53 +10:00
}
2005-04-16 15:20:36 -07:00
2020-10-19 09:57:16 +05:30
static bool update_mask_by_l2 ( int cpu , cpumask_var_t * mask )
2013-08-12 16:28:47 +10:00
{
2020-09-21 15:26:51 +05:30
struct cpumask * ( * submask_fn ) ( int ) = cpu_sibling_mask ;
2013-08-12 16:29:33 +10:00
struct device_node * l2_cache , * np ;
2017-06-29 17:12:53 +10:00
int i ;
2013-08-12 16:29:33 +10:00
2020-10-19 09:57:15 +05:30
if ( has_big_cores )
submask_fn = cpu_smallcore_mask ;
powerpc/smp: Add support detecting thread-groups sharing L2 cache
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com
2020-12-10 16:08:58 +05:30
/*
* If the threads in a thread - group share L2 cache , then the
* L2 - mask can be obtained from thread_group_l2_cache_map .
*/
if ( thread_group_shares_l2 ) {
cpumask_set_cpu ( cpu , cpu_l2_cache_mask ( cpu ) ) ;
for_each_cpu ( i , per_cpu ( thread_group_l2_cache_map , cpu ) ) {
if ( cpu_online ( i ) )
set_cpus_related ( i , cpu , cpu_l2_cache_mask ) ;
}
/* Verify that L1-cache siblings are a subset of L2 cache-siblings */
if ( ! cpumask_equal ( submask_fn ( cpu ) , cpu_l2_cache_mask ( cpu ) ) & &
! cpumask_subset ( submask_fn ( cpu ) , cpu_l2_cache_mask ( cpu ) ) ) {
pr_warn_once ( " CPU %d : Inconsistent L1 and L2 cache siblings \n " ,
cpu ) ;
}
return true ;
}
2013-08-12 16:28:47 +10:00
l2_cache = cpu_to_l2cache ( cpu ) ;
2020-10-19 09:57:16 +05:30
if ( ! l2_cache | | ! * mask ) {
/* Assume only core siblings share cache with this CPU */
powerpc/smp: Enable CACHE domain for shared processor
Currently CACHE domain is not enabled on shared processor mode PowerVM
LPARS. On PowerVM systems, 'ibm,thread-group' device-tree property 2
under cpu-device-node indicates which all CPUs share L2-cache. However
'ibm,thread-group' device-tree property 2 is a relatively new property.
In absence of 'ibm,thread-group' property 2, 'l2-cache' device property
under cpu-device-node could help system to identify CPUs sharing L2-cache.
However this property is not exposed by PhyP in shared processor mode
configurations.
In absence of properties that inform OS about which CPUs share L2-cache,
fallback on core boundary.
Here are some stats from Power9 shared LPAR with the changes.
$ lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 8
Core(s) per socket: 1
Socket(s): 3
NUMA node(s): 2
Model: 2.2 (pvr 004e 0202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: pHyp
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 16-23
NUMA node1 CPU(s): 0-15,24-31
Physical sockets: 2
Physical chips: 1
Physical cores/chip: 10
Before patch
$ grep -r . /sys/kernel/debug/sched/domains/cpu0/domain*/name
Before
/sys/kernel/debug/sched/domains/cpu0/domain0/name:SMT
/sys/kernel/debug/sched/domains/cpu0/domain1/name:DIE
/sys/kernel/debug/sched/domains/cpu0/domain2/name:NUMA
After
/sys/kernel/debug/sched/domains/cpu0/domain0/name:SMT
/sys/kernel/debug/sched/domains/cpu0/domain1/name:CACHE
/sys/kernel/debug/sched/domains/cpu0/domain2/name:DIE
/sys/kernel/debug/sched/domains/cpu0/domain3/name:NUMA
$ awk '/domain/{print $1, $2}' /proc/schedstat | sort -u | sed -e 's/00000000,//g'
Before
domain0 00000055
domain0 000000aa
domain0 00005500
domain0 0000aa00
domain0 00550000
domain0 00aa0000
domain0 55000000
domain0 aa000000
domain1 00ff0000
domain1 ff00ffff
domain2 ffffffff
After
domain0 00000055
domain0 000000aa
domain0 00005500
domain0 0000aa00
domain0 00550000
domain0 00aa0000
domain0 55000000
domain0 aa000000
domain1 000000ff
domain1 0000ff00
domain1 00ff0000
domain1 ff000000
domain2 ff00ffff
domain2 ffffffff
domain3 ffffffff
(Lower is better)
perf stat -a -r 5 -n perf bench sched pipe | tail -n 2
Before
153.798 +- 0.142 seconds time elapsed ( +- 0.09% )
After
111.545 +- 0.652 seconds time elapsed ( +- 0.58% )
which is an improvement of 27.47%
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210826100401.412519-4-srikar@linux.vnet.ibm.com
2021-08-26 15:34:01 +05:30
for_each_cpu ( i , cpu_sibling_mask ( cpu ) )
2020-09-13 22:40:38 +05:30
set_cpus_related ( cpu , i , cpu_l2_cache_mask ) ;
2017-06-29 17:12:54 +10:00
return false ;
2020-09-13 22:40:38 +05:30
}
2017-06-29 17:12:54 +10:00
2020-10-19 09:57:16 +05:30
cpumask_and ( * mask , cpu_online_mask , cpu_cpu_mask ( cpu ) ) ;
2020-09-21 15:26:51 +05:30
/* Update l2-cache mask with all the CPUs that are part of submask */
or_cpumasks_related ( cpu , cpu , submask_fn , cpu_l2_cache_mask ) ;
/* Skip all CPUs already part of current CPU l2-cache mask */
2020-10-19 09:57:16 +05:30
cpumask_andnot ( * mask , * mask , cpu_l2_cache_mask ( cpu ) ) ;
2020-09-21 15:26:51 +05:30
2020-10-19 09:57:16 +05:30
for_each_cpu ( i , * mask ) {
2017-06-29 17:12:54 +10:00
/*
* when updating the marks the current CPU has not been marked
* online , but we need to update the cache masks
*/
2013-08-12 16:29:33 +10:00
np = cpu_to_l2cache ( i ) ;
2017-06-29 17:12:54 +10:00
2020-09-21 15:26:51 +05:30
/* Skip all CPUs already part of current CPU l2-cache */
if ( np = = l2_cache ) {
or_cpumasks_related ( cpu , i , submask_fn , cpu_l2_cache_mask ) ;
2020-10-19 09:57:16 +05:30
cpumask_andnot ( * mask , * mask , submask_fn ( i ) ) ;
2020-09-21 15:26:51 +05:30
} else {
2020-10-19 09:57:16 +05:30
cpumask_andnot ( * mask , * mask , cpu_l2_cache_mask ( i ) ) ;
2020-09-21 15:26:51 +05:30
}
2017-06-29 17:12:54 +10:00
2013-08-12 16:28:47 +10:00
of_node_put ( np ) ;
}
of_node_put ( l2_cache ) ;
2017-06-29 17:12:54 +10:00
return true ;
}
# ifdef CONFIG_HOTPLUG_CPU
static void remove_cpu_from_masks ( int cpu )
{
2020-09-21 15:26:46 +05:30
struct cpumask * ( * mask_fn ) ( int ) = cpu_sibling_mask ;
2017-06-29 17:12:54 +10:00
int i ;
2021-08-26 15:35:20 +05:30
unmap_cpu_from_node ( cpu ) ;
2020-09-21 15:26:46 +05:30
if ( shared_caches )
mask_fn = cpu_l2_cache_mask ;
for_each_cpu ( i , mask_fn ( cpu ) ) {
2017-06-29 17:12:55 +10:00
set_cpus_unrelated ( cpu , i , cpu_l2_cache_mask ) ;
2017-06-29 17:12:54 +10:00
set_cpus_unrelated ( cpu , i , cpu_sibling_mask ) ;
2018-10-11 11:03:01 +05:30
if ( has_big_cores )
set_cpus_unrelated ( cpu , i , cpu_smallcore_mask ) ;
2020-09-21 15:26:46 +05:30
}
2021-04-15 17:39:32 +05:30
for_each_cpu ( i , cpu_core_mask ( cpu ) )
set_cpus_unrelated ( cpu , i , cpu_core_mask ) ;
2020-09-21 15:26:46 +05:30
if ( has_coregroup_support ( ) ) {
for_each_cpu ( i , cpu_coregroup_mask ( cpu ) )
2020-08-10 12:48:33 +05:30
set_cpus_unrelated ( cpu , i , cpu_coregroup_mask ) ;
2017-06-29 17:12:54 +10:00
}
}
# endif
2018-10-11 11:03:01 +05:30
static inline void add_cpu_to_smallcore_masks ( int cpu )
{
2020-09-21 15:26:49 +05:30
int i ;
2018-10-11 11:03:01 +05:30
if ( ! has_big_cores )
return ;
cpumask_set_cpu ( cpu , cpu_smallcore_mask ( cpu ) ) ;
2020-12-10 16:08:56 +05:30
for_each_cpu ( i , per_cpu ( thread_group_l1_cache_map , cpu ) ) {
2020-09-21 15:26:49 +05:30
if ( cpu_online ( i ) )
2018-10-11 11:03:01 +05:30
set_cpus_related ( i , cpu , cpu_smallcore_mask ) ;
}
}
2020-10-19 09:57:16 +05:30
static void update_coregroup_mask ( int cpu , cpumask_var_t * mask )
2020-09-21 15:26:52 +05:30
{
2020-09-21 15:26:53 +05:30
struct cpumask * ( * submask_fn ) ( int ) = cpu_sibling_mask ;
2020-09-21 15:26:52 +05:30
int coregroup_id = cpu_to_coregroup_id ( cpu ) ;
int i ;
2020-09-21 15:26:53 +05:30
if ( shared_caches )
submask_fn = cpu_l2_cache_mask ;
2020-10-19 09:57:16 +05:30
if ( ! * mask ) {
/* Assume only siblings are part of this CPU's coregroup */
for_each_cpu ( i , submask_fn ( cpu ) )
set_cpus_related ( cpu , i , cpu_coregroup_mask ) ;
return ;
}
cpumask_and ( * mask , cpu_online_mask , cpu_cpu_mask ( cpu ) ) ;
2020-09-21 15:26:53 +05:30
/* Update coregroup mask with all the CPUs that are part of submask */
or_cpumasks_related ( cpu , cpu , submask_fn , cpu_coregroup_mask ) ;
/* Skip all CPUs already part of coregroup mask */
2020-10-19 09:57:16 +05:30
cpumask_andnot ( * mask , * mask , cpu_coregroup_mask ( cpu ) ) ;
2020-09-21 15:26:52 +05:30
2020-10-19 09:57:16 +05:30
for_each_cpu ( i , * mask ) {
2020-09-21 15:26:53 +05:30
/* Skip all CPUs not part of this coregroup */
if ( coregroup_id = = cpu_to_coregroup_id ( i ) ) {
or_cpumasks_related ( cpu , i , submask_fn , cpu_coregroup_mask ) ;
2020-10-19 09:57:16 +05:30
cpumask_andnot ( * mask , * mask , submask_fn ( i ) ) ;
2020-09-21 15:26:53 +05:30
} else {
2020-10-19 09:57:16 +05:30
cpumask_andnot ( * mask , * mask , cpu_coregroup_mask ( i ) ) ;
2020-09-21 15:26:53 +05:30
}
2020-09-21 15:26:52 +05:30
}
}
2017-06-29 17:12:54 +10:00
static void add_cpu_to_masks ( int cpu )
{
2021-04-15 17:39:32 +05:30
struct cpumask * ( * submask_fn ) ( int ) = cpu_sibling_mask ;
2017-06-29 17:12:54 +10:00
int first_thread = cpu_first_thread_sibling ( cpu ) ;
2020-10-19 09:57:16 +05:30
cpumask_var_t mask ;
2021-04-15 17:39:34 +05:30
int chip_id = - 1 ;
2021-04-15 17:39:32 +05:30
bool ret ;
2017-06-29 17:12:54 +10:00
int i ;
/*
* This CPU will not be in the online mask yet so we need to manually
* add it to it ' s own thread sibling mask .
*/
2021-08-26 15:35:20 +05:30
map_cpu_to_node ( cpu , cpu_to_node ( cpu ) ) ;
2017-06-29 17:12:54 +10:00
cpumask_set_cpu ( cpu , cpu_sibling_mask ( cpu ) ) ;
powerpc/smp: Update cpu_core_map on all PowerPc systems
lscpu() uses core_siblings to list the number of sockets in the
system. core_siblings is set using topology_core_cpumask.
While optimizing the powerpc bootup path, Commit 4ca234a9cbd7
("powerpc/smp: Stop updating cpu_core_mask"). it was found that
updating cpu_core_mask() ended up taking a lot of time. It was thought
that on Powerpc, cpu_core_mask() would always be same as
cpu_cpu_mask() i.e number of sockets will always be equal to number of
nodes. As an optimization, cpu_core_mask() was made a snapshot of
cpu_cpu_mask().
However that was found to be false with PowerPc KVM guests, where each
node could have more than one socket. So with Commit c47f892d7aa6
("powerpc/smp: Reintroduce cpu_core_mask"), cpu_core_mask was updated
based on chip_id but in an optimized way using some mask manipulations
and chip_id caching.
However on non-PowerNV and non-pseries KVM guests (i.e not
implementing cpu_to_chip_id(), continued to use a copy of
cpu_cpu_mask().
There are two issues that were noticed on such systems
1. lscpu would report one extra socket.
On a IBM,9009-42A (aka zz system) which has only 2 chips/ sockets/
nodes, lscpu would report
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 160
On-line CPU(s) list: 0-159
Thread(s) per core: 8
Core(s) per socket: 6
Socket(s): 3 <--------------
NUMA node(s): 2
Model: 2.2 (pvr 004e 0202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: pHyp
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
L2 cache: 512K
L3 cache: 10240K
NUMA node0 CPU(s): 0-79
NUMA node1 CPU(s): 80-159
2. Currently cpu_cpu_mask is updated when a core is
added/removed. However its not updated when smt mode switching or on
CPUs are explicitly offlined. However all other percpu masks are
updated to ensure only active/online CPUs are in the masks.
This results in build_sched_domain traces since there will be CPUs in
cpu_cpu_mask() but those CPUs are not present in SMT / CACHE / MC /
NUMA domains. A loop of threads running smt mode switching and core
add/remove will soon show this trace.
Hence cpu_cpu_mask has to be update at smt mode switch.
This will have impact on cpu_core_mask(). cpu_core_mask() is a
snapshot of cpu_cpu_mask. Different CPUs within the same socket will
end up having different cpu_core_masks since they are snapshots at
different points of time. This means when lscpu will start reporting
many more sockets than the actual number of sockets/ nodes / chips.
Different ways to handle this problem:
A. Update the snapshot aka cpu_core_mask for all CPUs whenever
cpu_cpu_mask is updated. This would a non-optimal solution.
B. Instead of a cpumask_var_t, make cpu_core_map a cpumask pointer
pointing to cpu_cpu_mask. However percpu cpumask pointer is frowned
upon and we need a clean way to handle PowerPc KVM guest which is
not a snapshot.
C. Update cpu_core_masks all PowerPc systems like in PowerPc KVM
guests using mask manipulations. This approach is relatively simple
and unifies with the existing code.
D. On top of 3, we could also resurrect get_physical_package_id which
could return a nid for the said CPU. However this is not needed at this
time.
Option C is the preferred approach for now.
While this is somewhat a revert of Commit 4ca234a9cbd7 ("powerpc/smp:
Stop updating cpu_core_mask").
1. Plain revert has some conflicts
2. For chip_id == -1, the cpu_core_mask is made identical to
cpu_cpu_mask, unlike previously where cpu_core_mask was set to a core
if chip_id doesn't exist.
This goes by the principle that if chip_id is not exposed, then
sockets / chip / node share the same set of CPUs.
With the fix, lscpu o/p would be
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 160
On-line CPU(s) list: 0-159
Thread(s) per core: 8
Core(s) per socket: 6
Socket(s): 2 <--------------
NUMA node(s): 2
Model: 2.2 (pvr 004e 0202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: pHyp
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
L2 cache: 512K
L3 cache: 10240K
NUMA node0 CPU(s): 0-79
NUMA node1 CPU(s): 80-159
Fixes: 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask")
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210826100401.412519-3-srikar@linux.vnet.ibm.com
2021-08-26 15:34:00 +05:30
cpumask_set_cpu ( cpu , cpu_core_mask ( cpu ) ) ;
2017-06-29 17:12:54 +10:00
for ( i = first_thread ; i < first_thread + threads_per_core ; i + + )
if ( cpu_online ( i ) )
set_cpus_related ( i , cpu , cpu_sibling_mask ) ;
2018-10-11 11:03:01 +05:30
add_cpu_to_smallcore_masks ( cpu ) ;
2020-10-19 09:57:16 +05:30
/* In CPU-hotplug path, hence use GFP_ATOMIC */
2021-04-15 17:39:32 +05:30
ret = alloc_cpumask_var_node ( & mask , GFP_ATOMIC , cpu_to_node ( cpu ) ) ;
2020-10-19 09:57:16 +05:30
update_mask_by_l2 ( cpu , & mask ) ;
2017-06-29 17:12:55 +10:00
2020-09-21 15:26:52 +05:30
if ( has_coregroup_support ( ) )
2020-10-19 09:57:16 +05:30
update_coregroup_mask ( cpu , & mask ) ;
2021-04-15 17:39:34 +05:30
if ( chip_id_lookup_table & & ret )
chip_id = cpu_to_chip_id ( cpu ) ;
2021-04-15 17:39:32 +05:30
if ( shared_caches )
submask_fn = cpu_l2_cache_mask ;
/* Update core_mask with all the CPUs that are part of submask */
or_cpumasks_related ( cpu , cpu , submask_fn , cpu_core_mask ) ;
/* Skip all CPUs already part of current CPU core mask */
cpumask_andnot ( mask , cpu_online_mask , cpu_core_mask ( cpu ) ) ;
powerpc/smp: Update cpu_core_map on all PowerPc systems
lscpu() uses core_siblings to list the number of sockets in the
system. core_siblings is set using topology_core_cpumask.
While optimizing the powerpc bootup path, Commit 4ca234a9cbd7
("powerpc/smp: Stop updating cpu_core_mask"). it was found that
updating cpu_core_mask() ended up taking a lot of time. It was thought
that on Powerpc, cpu_core_mask() would always be same as
cpu_cpu_mask() i.e number of sockets will always be equal to number of
nodes. As an optimization, cpu_core_mask() was made a snapshot of
cpu_cpu_mask().
However that was found to be false with PowerPc KVM guests, where each
node could have more than one socket. So with Commit c47f892d7aa6
("powerpc/smp: Reintroduce cpu_core_mask"), cpu_core_mask was updated
based on chip_id but in an optimized way using some mask manipulations
and chip_id caching.
However on non-PowerNV and non-pseries KVM guests (i.e not
implementing cpu_to_chip_id(), continued to use a copy of
cpu_cpu_mask().
There are two issues that were noticed on such systems
1. lscpu would report one extra socket.
On a IBM,9009-42A (aka zz system) which has only 2 chips/ sockets/
nodes, lscpu would report
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 160
On-line CPU(s) list: 0-159
Thread(s) per core: 8
Core(s) per socket: 6
Socket(s): 3 <--------------
NUMA node(s): 2
Model: 2.2 (pvr 004e 0202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: pHyp
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
L2 cache: 512K
L3 cache: 10240K
NUMA node0 CPU(s): 0-79
NUMA node1 CPU(s): 80-159
2. Currently cpu_cpu_mask is updated when a core is
added/removed. However its not updated when smt mode switching or on
CPUs are explicitly offlined. However all other percpu masks are
updated to ensure only active/online CPUs are in the masks.
This results in build_sched_domain traces since there will be CPUs in
cpu_cpu_mask() but those CPUs are not present in SMT / CACHE / MC /
NUMA domains. A loop of threads running smt mode switching and core
add/remove will soon show this trace.
Hence cpu_cpu_mask has to be update at smt mode switch.
This will have impact on cpu_core_mask(). cpu_core_mask() is a
snapshot of cpu_cpu_mask. Different CPUs within the same socket will
end up having different cpu_core_masks since they are snapshots at
different points of time. This means when lscpu will start reporting
many more sockets than the actual number of sockets/ nodes / chips.
Different ways to handle this problem:
A. Update the snapshot aka cpu_core_mask for all CPUs whenever
cpu_cpu_mask is updated. This would a non-optimal solution.
B. Instead of a cpumask_var_t, make cpu_core_map a cpumask pointer
pointing to cpu_cpu_mask. However percpu cpumask pointer is frowned
upon and we need a clean way to handle PowerPc KVM guest which is
not a snapshot.
C. Update cpu_core_masks all PowerPc systems like in PowerPc KVM
guests using mask manipulations. This approach is relatively simple
and unifies with the existing code.
D. On top of 3, we could also resurrect get_physical_package_id which
could return a nid for the said CPU. However this is not needed at this
time.
Option C is the preferred approach for now.
While this is somewhat a revert of Commit 4ca234a9cbd7 ("powerpc/smp:
Stop updating cpu_core_mask").
1. Plain revert has some conflicts
2. For chip_id == -1, the cpu_core_mask is made identical to
cpu_cpu_mask, unlike previously where cpu_core_mask was set to a core
if chip_id doesn't exist.
This goes by the principle that if chip_id is not exposed, then
sockets / chip / node share the same set of CPUs.
With the fix, lscpu o/p would be
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 160
On-line CPU(s) list: 0-159
Thread(s) per core: 8
Core(s) per socket: 6
Socket(s): 2 <--------------
NUMA node(s): 2
Model: 2.2 (pvr 004e 0202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: pHyp
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
L2 cache: 512K
L3 cache: 10240K
NUMA node0 CPU(s): 0-79
NUMA node1 CPU(s): 80-159
Fixes: 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask")
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210826100401.412519-3-srikar@linux.vnet.ibm.com
2021-08-26 15:34:00 +05:30
/* If chip_id is -1; limit the cpu_core_mask to within DIE*/
if ( chip_id = = - 1 )
cpumask_and ( mask , mask , cpu_cpu_mask ( cpu ) ) ;
2021-04-15 17:39:32 +05:30
for_each_cpu ( i , mask ) {
if ( chip_id = = cpu_to_chip_id ( i ) ) {
or_cpumasks_related ( cpu , i , submask_fn , cpu_core_mask ) ;
cpumask_andnot ( mask , mask , submask_fn ( i ) ) ;
} else {
cpumask_andnot ( mask , mask , cpu_core_mask ( i ) ) ;
}
}
2020-10-19 09:57:16 +05:30
free_cpumask_var ( mask ) ;
2013-08-12 16:28:47 +10:00
}
2005-04-16 15:20:36 -07:00
/* Activate a secondary processor. */
2013-06-24 15:30:09 -04:00
void start_secondary ( void * unused )
2005-04-16 15:20:36 -07:00
{
2020-10-28 14:23:34 -04:00
unsigned int cpu = raw_smp_processor_id ( ) ;
2005-04-16 15:20:36 -07:00
2021-06-03 08:41:41 +00:00
/* PPC64 calls setup_kup() in early_setup_secondary() */
if ( IS_ENABLED ( CONFIG_PPC32 ) )
setup_kup ( ) ;
2017-02-27 14:30:07 -08:00
mmgrab ( & init_mm ) ;
2005-04-16 15:20:36 -07:00
current - > active_mm = & init_mm ;
smp_store_cpu_info ( cpu ) ;
2005-11-05 10:33:55 +11:00
set_dec ( tb_ticks_per_jiffy ) ;
2020-10-28 14:23:34 -04:00
rcu_cpu_starting ( cpu ) ;
2014-12-29 15:47:05 +11:00
cpu_callin_map [ cpu ] = 1 ;
2005-04-16 15:20:36 -07:00
2009-09-08 17:38:52 +00:00
if ( smp_ops - > setup_cpu )
smp_ops - > setup_cpu ( cpu ) ;
2005-04-16 15:20:36 -07:00
if ( smp_ops - > take_timebase )
smp_ops - > take_timebase ( ) ;
2007-09-21 13:26:03 +10:00
secondary_cpu_time_init ( ) ;
2011-03-08 14:49:33 +11:00
# ifdef CONFIG_PPC64
if ( system_state = = SYSTEM_RUNNING )
vdso_data - > processorCount + + ;
2012-07-04 20:37:11 +00:00
vdso_getcpu_init ( ) ;
2011-03-08 14:49:33 +11:00
# endif
2021-04-01 21:12:00 +05:30
set_numa_node ( numa_cpu_lookup_table [ cpu ] ) ;
set_numa_mem ( local_memory_node ( numa_cpu_lookup_table [ cpu ] ) ) ;
2017-06-29 17:12:54 +10:00
/* Update topology CPU masks */
add_cpu_to_masks ( cpu ) ;
2005-04-16 15:20:36 -07:00
2017-06-29 17:12:56 +10:00
/*
* Check for any shared caches . Note that this must be done on a
* per - core basis because one core in the pair might be disabled .
*/
2020-08-10 12:48:30 +05:30
if ( ! shared_caches ) {
struct cpumask * ( * sibling_mask ) ( int ) = cpu_sibling_mask ;
struct cpumask * mask = cpu_l2_cache_mask ( cpu ) ;
if ( has_big_cores )
sibling_mask = cpu_smallcore_mask ;
if ( cpumask_weight ( mask ) > cpumask_weight ( sibling_mask ( cpu ) ) )
shared_caches = true ;
}
2017-06-29 17:12:56 +10:00
powerpc: Set cpu sibling mask before online cpu
It seems following race is possible:
cpu0 cpux
smp_init->cpu_up->_cpu_up
__cpu_up
kick_cpu(1)
-------------------------------------------------------------------------
waiting online ...
... notify CPU_STARTING
set cpux active
set cpux online
-------------------------------------------------------------------------
finish waiting online
...
sched_init_smp
init_sched_domains(cpu_active_mask)
build_sched_domains
set cpux sibling info
-------------------------------------------------------------------------
Execution of cpu0 and cpux could be concurrent between two separator
lines.
So if the cpux sibling information was set too late (normally
impossible, but could be triggered by adding some delay in
start_secondary, after setting cpu online), build_sched_domains()
running on cpu0 might see cpux active, with an empty sibling mask, then
cause some bad address accessing like following:
[ 0.099855] Unable to handle kernel paging request for data at address 0xc00000038518078f
[ 0.099868] Faulting instruction address: 0xc0000000000b7a64
[ 0.099883] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.099895] PREEMPT SMP NR_CPUS=16 DEBUG_PAGEALLOC NUMA pSeries
[ 0.099922] Modules linked in:
[ 0.099940] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc1-00120-gb973425-dirty #16
[ 0.099956] task: c0000001fed80000 ti: c0000001fed7c000 task.ti: c0000001fed7c000
[ 0.099971] NIP: c0000000000b7a64 LR: c0000000000b7a40 CTR: c0000000000b4934
[ 0.099985] REGS: c0000001fed7f760 TRAP: 0300 Not tainted (3.10.0-rc1-00120-gb973425-dirty)
[ 0.099997] MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24272828 XER: 20000003
[ 0.100045] SOFTE: 1
[ 0.100053] CFAR: c000000000445ee8
[ 0.100064] DAR: c00000038518078f, DSISR: 40000000
[ 0.100073]
GPR00: 0000000000000080 c0000001fed7f9e0 c000000000c84d48 0000000000000010
GPR04: 0000000000000010 0000000000000000 c0000001fc55e090 0000000000000000
GPR08: ffffffffffffffff c000000000b80b30 c000000000c962d8 00000003845ffc5f
GPR12: 0000000000000000 c00000000f33d000 c00000000000b9e4 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000001 0000000000000000
GPR20: c000000000ccf750 0000000000000000 c000000000c94d48 c0000001fc504000
GPR24: c0000001fc504000 c0000001fecef848 c000000000c94d48 c000000000ccf000
GPR28: c0000001fc522090 0000000000000010 c0000001fecef848 c0000001fed7fae0
[ 0.100293] NIP [c0000000000b7a64] .get_group+0x84/0xc4
[ 0.100307] LR [c0000000000b7a40] .get_group+0x60/0xc4
[ 0.100318] Call Trace:
[ 0.100332] [c0000001fed7f9e0] [c0000000000dbce4] .lock_is_held+0xa8/0xd0 (unreliable)
[ 0.100354] [c0000001fed7fa70] [c0000000000bf62c] .build_sched_domains+0x728/0xd14
[ 0.100375] [c0000001fed7fbe0] [c000000000af67bc] .sched_init_smp+0x4fc/0x654
[ 0.100394] [c0000001fed7fce0] [c000000000adce24] .kernel_init_freeable+0x17c/0x30c
[ 0.100413] [c0000001fed7fdb0] [c00000000000ba08] .kernel_init+0x24/0x12c
[ 0.100431] [c0000001fed7fe30] [c000000000009f74] .ret_from_kernel_thread+0x5c/0x68
[ 0.100445] Instruction dump:
[ 0.100456] 38800010 38a00000 4838e3f5 60000000 7c6307b4 2fbf0000 419e0040 3d220001
[ 0.100496] 78601f24 39491590 e93e0008 7d6a002a <7d69582a> f97f0000 7d4a002a e93e0010
[ 0.100559] ---[ end trace 31fd0ba7d8756001 ]---
This patch tries to move the sibling maps updating before
notify_cpu_starting() and cpu online, and a write barrier there to make
sure sibling maps are updated before active and online mask.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-16 18:20:26 +08:00
smp_wmb ( ) ;
notify_cpu_starting ( cpu ) ;
set_cpu_online ( cpu , true ) ;
2018-10-19 16:19:10 +11:00
boot_init_stack_canary ( ) ;
2005-04-16 15:20:36 -07:00
local_irq_enable ( ) ;
2018-04-19 12:34:03 +05:30
/* We can enable ftrace for secondary cpus now */
this_cpu_enable_ftrace ( ) ;
2016-02-26 18:43:40 +00:00
cpu_startup_entry ( CPUHP_AP_ONLINE_IDLE ) ;
2011-02-10 18:45:24 +11:00
BUG ( ) ;
2005-04-16 15:20:36 -07:00
}
int setup_profiling_timer ( unsigned int multiplier )
{
return 0 ;
}
2020-08-10 12:48:28 +05:30
static void fixup_topology ( void )
{
2020-09-21 15:26:50 +05:30
int i ;
2020-08-10 12:48:28 +05:30
# ifdef CONFIG_SCHED_SMT
if ( has_big_cores ) {
pr_info ( " Big cores detected but using small core scheduling \n " ) ;
2020-08-10 12:48:33 +05:30
powerpc_topology [ smt_idx ] . mask = smallcore_smt_mask ;
2020-08-10 12:48:28 +05:30
}
# endif
2020-08-10 12:48:33 +05:30
if ( ! has_coregroup_support ( ) )
powerpc_topology [ mc_idx ] . mask = powerpc_topology [ cache_idx ] . mask ;
2020-09-21 15:26:50 +05:30
/*
* Try to consolidate topology levels here instead of
* allowing scheduler to degenerate .
* - Dont consolidate if masks are different .
* - Dont consolidate if sd_flags exists and are different .
*/
for ( i = 1 ; i < = die_idx ; i + + ) {
if ( powerpc_topology [ i ] . mask ! = powerpc_topology [ i - 1 ] . mask )
continue ;
if ( powerpc_topology [ i ] . sd_flags & & powerpc_topology [ i - 1 ] . sd_flags & &
powerpc_topology [ i ] . sd_flags ! = powerpc_topology [ i - 1 ] . sd_flags )
continue ;
if ( ! powerpc_topology [ i - 1 ] . sd_flags )
powerpc_topology [ i - 1 ] . sd_flags = powerpc_topology [ i ] . sd_flags ;
powerpc_topology [ i ] . mask = powerpc_topology [ i + 1 ] . mask ;
powerpc_topology [ i ] . sd_flags = powerpc_topology [ i + 1 ] . sd_flags ;
# ifdef CONFIG_SCHED_DEBUG
powerpc_topology [ i ] . name = powerpc_topology [ i + 1 ] . name ;
# endif
}
2020-08-10 12:48:28 +05:30
}
2017-04-12 22:07:31 +02:00
void __init smp_cpus_done ( unsigned int max_cpus )
{
/*
powerpc/smp: Call smp_ops->setup_cpu() directly on the boot CPU
In smp_cpus_done() we need to call smp_ops->setup_cpu() for the boot
CPU, which means it has to run *on* the boot CPU.
In the past we ensured it ran on the boot CPU by changing the CPU
affinity mask of current directly. That was removed in commit
6d11b87d55eb ("powerpc/smp: Replace open coded task affinity logic"),
and replaced with a work queue call.
Unfortunately using a work queue leads to a lockdep warning, now that
the CPU hotplug lock is a regular semaphore:
======================================================
WARNING: possible circular locking dependency detected
...
kworker/0:1/971 is trying to acquire lock:
(cpu_hotplug_lock.rw_sem){++++++}, at: [<c000000000100974>] apply_workqueue_attrs+0x34/0xa0
but task is already holding lock:
((&wfc.work)){+.+.+.}, at: [<c0000000000fdb2c>] process_one_work+0x25c/0x800
...
CPU0 CPU1
---- ----
lock((&wfc.work));
lock(cpu_hotplug_lock.rw_sem);
lock((&wfc.work));
lock(cpu_hotplug_lock.rw_sem);
Although the deadlock can't happen in practice, because
smp_cpus_done() only runs in early boot before CPU hotplug is allowed,
lockdep can't tell that.
Luckily in commit 8fb12156b8db ("init: Pin init task to the boot CPU,
initially") tglx changed the generic code to pin init to the boot CPU
to begin with. The unpinning of init from the boot CPU happens in
sched_init_smp(), which is called after smp_cpus_done().
So smp_cpus_done() is always called on the boot CPU, which means we
don't need the work queue call at all - and the lockdep warning goes
away.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
2017-07-27 23:23:37 +10:00
* We are running pinned to the boot CPU , see rest_init ( ) .
2005-04-16 15:20:36 -07:00
*/
2009-09-08 17:38:52 +00:00
if ( smp_ops & & smp_ops - > setup_cpu )
powerpc/smp: Call smp_ops->setup_cpu() directly on the boot CPU
In smp_cpus_done() we need to call smp_ops->setup_cpu() for the boot
CPU, which means it has to run *on* the boot CPU.
In the past we ensured it ran on the boot CPU by changing the CPU
affinity mask of current directly. That was removed in commit
6d11b87d55eb ("powerpc/smp: Replace open coded task affinity logic"),
and replaced with a work queue call.
Unfortunately using a work queue leads to a lockdep warning, now that
the CPU hotplug lock is a regular semaphore:
======================================================
WARNING: possible circular locking dependency detected
...
kworker/0:1/971 is trying to acquire lock:
(cpu_hotplug_lock.rw_sem){++++++}, at: [<c000000000100974>] apply_workqueue_attrs+0x34/0xa0
but task is already holding lock:
((&wfc.work)){+.+.+.}, at: [<c0000000000fdb2c>] process_one_work+0x25c/0x800
...
CPU0 CPU1
---- ----
lock((&wfc.work));
lock(cpu_hotplug_lock.rw_sem);
lock((&wfc.work));
lock(cpu_hotplug_lock.rw_sem);
Although the deadlock can't happen in practice, because
smp_cpus_done() only runs in early boot before CPU hotplug is allowed,
lockdep can't tell that.
Luckily in commit 8fb12156b8db ("init: Pin init task to the boot CPU,
initially") tglx changed the generic code to pin init to the boot CPU
to begin with. The unpinning of init from the boot CPU happens in
sched_init_smp(), which is called after smp_cpus_done().
So smp_cpus_done() is always called on the boot CPU, which means we
don't need the work queue call at all - and the lockdep warning goes
away.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
2017-07-27 23:23:37 +10:00
smp_ops - > setup_cpu ( boot_cpuid ) ;
2005-12-13 06:56:47 +11:00
2011-03-08 13:50:37 +11:00
if ( smp_ops & & smp_ops - > bringup_done )
smp_ops - > bringup_done ( ) ;
2005-12-13 06:56:47 +11:00
dump_numa_cpu_topology ( ) ;
2011-03-08 13:50:37 +11:00
2020-08-10 12:48:28 +05:30
fixup_topology ( ) ;
2020-08-10 12:48:26 +05:30
set_sched_topology ( powerpc_topology ) ;
2010-08-10 20:02:05 +00:00
}
2005-04-16 15:20:36 -07:00
# ifdef CONFIG_HOTPLUG_CPU
int __cpu_disable ( void )
{
2008-07-27 15:24:52 +10:00
int cpu = smp_processor_id ( ) ;
int err ;
2005-04-16 15:20:36 -07:00
2008-07-27 15:24:52 +10:00
if ( ! smp_ops - > cpu_disable )
return - ENOSYS ;
2018-04-19 12:34:04 +05:30
this_cpu_disable_ftrace ( ) ;
2008-07-27 15:24:52 +10:00
err = smp_ops - > cpu_disable ( ) ;
if ( err )
return err ;
/* Update sibling maps */
2017-06-29 17:12:54 +10:00
remove_cpu_from_masks ( cpu ) ;
2008-07-27 15:24:52 +10:00
return 0 ;
2005-04-16 15:20:36 -07:00
}
void __cpu_die ( unsigned int cpu )
{
if ( smp_ops - > cpu_die )
smp_ops - > cpu_die ( cpu ) ;
}
2010-01-14 09:52:44 +00:00
2020-08-19 11:56:32 +10:00
void arch_cpu_idle_dead ( void )
{
sched_preempt_enable_no_resched ( ) ;
2018-04-19 12:34:04 +05:30
/*
* Disable on the down path . This will be re - enabled by
* start_secondary ( ) via start_secondary_resume ( ) below
*/
this_cpu_disable_ftrace ( ) ;
2020-08-19 11:56:34 +10:00
if ( smp_ops - > cpu_offline_self )
smp_ops - > cpu_offline_self ( ) ;
2011-02-10 18:45:24 +11:00
/* If we return, we re-enter start_secondary */
start_secondary_resume ( ) ;
2010-05-19 02:56:29 +00:00
}
2011-02-10 18:45:24 +11:00
2005-04-16 15:20:36 -07:00
# endif