Like L2-cache info, coregroup information which is used to determine MC
sched domains is only present on dedicated LPARs. i.e PowerVM doesn't
export coregroup information for shared processor LPARs. Hence disable
creating MC domains on shared LPAR Systems.
Signed-off-by: Srikar Dronamraju <[email protected]>
---
arch/powerpc/kernel/smp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 498c2d51fc20..29da9262cb17 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1046,6 +1046,10 @@ static struct cpumask *cpu_coregroup_mask(int cpu)
static bool has_coregroup_support(void)
{
+ /* Coregroup identification not available on shared systems */
+ if (is_shared_processor())
+ return 0;
+
return coregroup_enabled;
}
--
2.31.1
Srikar Dronamraju <[email protected]> writes:
> Like L2-cache info, coregroup information which is used to determine MC
> sched domains is only present on dedicated LPARs. i.e PowerVM doesn't
> export coregroup information for shared processor LPARs. Hence disable
> creating MC domains on shared LPAR Systems.
>
> Signed-off-by: Srikar Dronamraju <[email protected]>
> ---
> arch/powerpc/kernel/smp.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 498c2d51fc20..29da9262cb17 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1046,6 +1046,10 @@ static struct cpumask *cpu_coregroup_mask(int cpu)
>
> static bool has_coregroup_support(void)
> {
> + /* Coregroup identification not available on shared systems */
> + if (is_shared_processor())
> + return 0;
That will catch guests running under KVM too right? Do we want that?
> return coregroup_enabled;
What does coregroup_enabled mean now?
I'd rather this was actually checking the presence of something, rather
than just hard coding that shared processor means no coregroup support.
cheers
On Thu, Oct 19, 2023 at 03:48:48PM +1100, Michael Ellerman wrote:
> Srikar Dronamraju <[email protected]> writes:
> > Like L2-cache info, coregroup information which is used to determine MC
> > sched domains is only present on dedicated LPARs. i.e PowerVM doesn't
> > export coregroup information for shared processor LPARs. Hence disable
> > creating MC domains on shared LPAR Systems.
> >
> > Signed-off-by: Srikar Dronamraju <[email protected]>
> > ---
> > arch/powerpc/kernel/smp.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index 498c2d51fc20..29da9262cb17 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -1046,6 +1046,10 @@ static struct cpumask *cpu_coregroup_mask(int cpu)
> >
> > static bool has_coregroup_support(void)
> > {
> > + /* Coregroup identification not available on shared systems */
> > + if (is_shared_processor())
> > + return 0;
>
> That will catch guests running under KVM too right? Do we want that?
Some KVM people use vcpu pinning and pass-through topology things,
slice-of-hardware or something like that. In that scenario you actively
do want this.
I'm fairly clueless on when this is_shared_processor() gets to be true,
so that might already be dealt with..
* Michael Ellerman <[email protected]> [2023-10-19 15:48:48]:
> Srikar Dronamraju <[email protected]> writes:
> > Like L2-cache info, coregroup information which is used to determine MC
> > sched domains is only present on dedicated LPARs. i.e PowerVM doesn't
> > export coregroup information for shared processor LPARs. Hence disable
> > creating MC domains on shared LPAR Systems.
> >
> > Signed-off-by: Srikar Dronamraju <[email protected]>
> > ---
> > arch/powerpc/kernel/smp.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index 498c2d51fc20..29da9262cb17 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -1046,6 +1046,10 @@ static struct cpumask *cpu_coregroup_mask(int cpu)
> >
> > static bool has_coregroup_support(void)
> > {
> > + /* Coregroup identification not available on shared systems */
> > + if (is_shared_processor())
> > + return 0;
>
> That will catch guests running under KVM too right? Do we want that?
>
Only dedicated LPARS on PowerVM expose coregroup or Hemisphere information.
Currently other systems including KVMs don't expose this information to the
OS.
> > return coregroup_enabled;
>
> What does coregroup_enabled mean now?
>
> I'd rather this was actually checking the presence of something, rather
> than just hard coding that shared processor means no coregroup support.
>
On a shared LPAR, the Hypervisors would like to have the flexibility to
schedule LPAR on any core within the DIE without having to further think
about the Hemisphere locality of the core.
> cheers
--
Thanks and Regards
Srikar Dronamraju
* Peter Zijlstra <[email protected]> [2023-10-19 09:50:46]:
> On Thu, Oct 19, 2023 at 03:48:48PM +1100, Michael Ellerman wrote:
> > Srikar Dronamraju <[email protected]> writes:
> > > Like L2-cache info, coregroup information which is used to determine MC
> > > sched domains is only present on dedicated LPARs. i.e PowerVM doesn't
> > > export coregroup information for shared processor LPARs. Hence disable
> > > creating MC domains on shared LPAR Systems.
> > >
> > > Signed-off-by: Srikar Dronamraju <[email protected]>
> > > ---
> > > arch/powerpc/kernel/smp.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > > index 498c2d51fc20..29da9262cb17 100644
> > > --- a/arch/powerpc/kernel/smp.c
> > > +++ b/arch/powerpc/kernel/smp.c
> > > @@ -1046,6 +1046,10 @@ static struct cpumask *cpu_coregroup_mask(int cpu)
> > >
> > > static bool has_coregroup_support(void)
> > > {
> > > + /* Coregroup identification not available on shared systems */
> > > + if (is_shared_processor())
> > > + return 0;
> >
> > That will catch guests running under KVM too right? Do we want that?
>
> Some KVM people use vcpu pinning and pass-through topology things,
> slice-of-hardware or something like that. In that scenario you actively
> do want this.
>
> I'm fairly clueless on when this is_shared_processor() gets to be true,
> so that might already be dealt with..
Dedicated LPARs are like pinned VM instances. There is a one-to-one mapping
between the Physical core and the virtual core.
On Shared LPARs are unlike regular unpinned VM instances. The Hypervisor
has the flexibility to schedule the virtual core on different Physical core
based on the availability. And like regular VMs, Shared LPARs also support
overcommiting i.e there can be more virtual cores than Physical cores. So
Hypervisor takes care of switching the cores based on its entitlement.
Hence On Shared LPARs, Hypervisors would like to keep the Hemisphere
locality of the cores transparent to the OS.
--
Thanks and Regards
Srikar Dronamraju