[PATCH 19/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated()

Frederic Weisbecker posted 33 patches 1 month ago
[PATCH 19/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated()
Posted by Frederic Weisbecker 1 month ago
It doesn't make sense to use nohz_full without also isolating the
related CPUs from the domain topology, either through the use of
isolcpus= or cpuset isolated partitions.

And now HK_TYPE_DOMAIN includes all kinds of domain isolated CPUs.

This means that HK_TYPE_KERNEL_NOISE (of which HK_TYPE_TICK is only an
alias) is always a superset of HK_TYPE_DOMAIN.

Therefore if a CPU is not HK_TYPE_KERNEL_NOISE, it can't be
HK_TYPE_DOMAIN either. Testing the latter is then enough.

Simplify cpu_is_isolated() accordingly.

Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 include/linux/sched/isolation.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/linux/sched/isolation.h b/include/linux/sched/isolation.h
index c02923ed4cbe..8d6d26d3fdf5 100644
--- a/include/linux/sched/isolation.h
+++ b/include/linux/sched/isolation.h
@@ -82,8 +82,7 @@ static inline void housekeeping_init(void) { }
 
 static inline bool cpu_is_isolated(int cpu)
 {
-	return !housekeeping_test_cpu(cpu, HK_TYPE_DOMAIN) ||
-	       !housekeeping_test_cpu(cpu, HK_TYPE_TICK);
+	return !housekeeping_test_cpu(cpu, HK_TYPE_DOMAIN);
 }
 
 #endif /* _LINUX_SCHED_ISOLATION_H */
-- 
2.51.0
Re: [PATCH 19/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated()
Posted by Waiman Long 1 month ago
On 8/29/25 11:48 AM, Frederic Weisbecker wrote:
> It doesn't make sense to use nohz_full without also isolating the
> related CPUs from the domain topology, either through the use of
> isolcpus= or cpuset isolated partitions.
>
> And now HK_TYPE_DOMAIN includes all kinds of domain isolated CPUs.
>
> This means that HK_TYPE_KERNEL_NOISE (of which HK_TYPE_TICK is only an
> alias) is always a superset of HK_TYPE_DOMAIN.

That may not be true. Users can still set "isolcpus=" and "nohz_full=" 
with disjoint set of CPUs whether cpuset is used for additional isolated 
CPUs or not.

Cheers,
Longman

>
> Therefore if a CPU is not HK_TYPE_KERNEL_NOISE, it can't be
> HK_TYPE_DOMAIN either. Testing the latter is then enough.
>
> Simplify cpu_is_isolated() accordingly.
>
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> ---
>   include/linux/sched/isolation.h | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/include/linux/sched/isolation.h b/include/linux/sched/isolation.h
> index c02923ed4cbe..8d6d26d3fdf5 100644
> --- a/include/linux/sched/isolation.h
> +++ b/include/linux/sched/isolation.h
> @@ -82,8 +82,7 @@ static inline void housekeeping_init(void) { }
>   
>   static inline bool cpu_is_isolated(int cpu)
>   {
> -	return !housekeeping_test_cpu(cpu, HK_TYPE_DOMAIN) ||
> -	       !housekeeping_test_cpu(cpu, HK_TYPE_TICK);
> +	return !housekeeping_test_cpu(cpu, HK_TYPE_DOMAIN);
>   }
>   
>   #endif /* _LINUX_SCHED_ISOLATION_H */
Re: [PATCH 19/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated()
Posted by Frederic Weisbecker 1 week, 3 days ago
Le Tue, Sep 02, 2025 at 10:28:58AM -0400, Waiman Long a écrit :
> 
> On 8/29/25 11:48 AM, Frederic Weisbecker wrote:
> > It doesn't make sense to use nohz_full without also isolating the
> > related CPUs from the domain topology, either through the use of
> > isolcpus= or cpuset isolated partitions.
> > 
> > And now HK_TYPE_DOMAIN includes all kinds of domain isolated CPUs.
> > 
> > This means that HK_TYPE_KERNEL_NOISE (of which HK_TYPE_TICK is only an
> > alias) is always a superset of HK_TYPE_DOMAIN.
> 
> That may not be true. Users can still set "isolcpus=" and "nohz_full=" with
> disjoint set of CPUs whether cpuset is used for additional isolated CPUs or
> not.

There can be domain isolated CPU that are not nohz_full indeed. But OTOH nohz_full
CPUs that are not domain isolated don't make much sense. I know such settings
exist but it's usually a half working misconfiguration. I wish I had
forbidden that since the early days but this was from times when we didn't know
about all the potential usages.

Thanks.



> 
> Cheers,
> Longman
> 
> > 
> > Therefore if a CPU is not HK_TYPE_KERNEL_NOISE, it can't be
> > HK_TYPE_DOMAIN either. Testing the latter is then enough.
> > 
> > Simplify cpu_is_isolated() accordingly.
> > 
> > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > ---
> >   include/linux/sched/isolation.h | 3 +--
> >   1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/sched/isolation.h b/include/linux/sched/isolation.h
> > index c02923ed4cbe..8d6d26d3fdf5 100644
> > --- a/include/linux/sched/isolation.h
> > +++ b/include/linux/sched/isolation.h
> > @@ -82,8 +82,7 @@ static inline void housekeeping_init(void) { }
> >   static inline bool cpu_is_isolated(int cpu)
> >   {
> > -	return !housekeeping_test_cpu(cpu, HK_TYPE_DOMAIN) ||
> > -	       !housekeeping_test_cpu(cpu, HK_TYPE_TICK);
> > +	return !housekeeping_test_cpu(cpu, HK_TYPE_DOMAIN);
> >   }
> >   #endif /* _LINUX_SCHED_ISOLATION_H */
> 

-- 
Frederic Weisbecker
SUSE Labs
Re: [PATCH 19/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated()
Posted by Waiman Long 1 week, 3 days ago
On 9/22/25 11:19 AM, Frederic Weisbecker wrote:
> Le Tue, Sep 02, 2025 at 10:28:58AM -0400, Waiman Long a écrit :
>> On 8/29/25 11:48 AM, Frederic Weisbecker wrote:
>>> It doesn't make sense to use nohz_full without also isolating the
>>> related CPUs from the domain topology, either through the use of
>>> isolcpus= or cpuset isolated partitions.
>>>
>>> And now HK_TYPE_DOMAIN includes all kinds of domain isolated CPUs.
>>>
>>> This means that HK_TYPE_KERNEL_NOISE (of which HK_TYPE_TICK is only an
>>> alias) is always a superset of HK_TYPE_DOMAIN.
>> That may not be true. Users can still set "isolcpus=" and "nohz_full=" with
>> disjoint set of CPUs whether cpuset is used for additional isolated CPUs or
>> not.
> There can be domain isolated CPU that are not nohz_full indeed. But OTOH nohz_full
> CPUs that are not domain isolated don't make much sense. I know such settings
> exist but it's usually a half working misconfiguration. I wish I had
> forbidden that since the early days but this was from times when we didn't know
> about all the potential usages.

The assumption is true for cpuset isolated partition, but users may 
still set conflicting nohz_full and isolcpus parameters by mistake. We 
should probably a warning if this happens and document that clearly to 
enforce such rule.

Cheers,
Longman

Re: [PATCH 19/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated()
Posted by Frederic Weisbecker 1 week, 3 days ago
Le Mon, Sep 22, 2025 at 05:59:12PM -0400, Waiman Long a écrit :
> 
> On 9/22/25 11:19 AM, Frederic Weisbecker wrote:
> > Le Tue, Sep 02, 2025 at 10:28:58AM -0400, Waiman Long a écrit :
> > > On 8/29/25 11:48 AM, Frederic Weisbecker wrote:
> > > > It doesn't make sense to use nohz_full without also isolating the
> > > > related CPUs from the domain topology, either through the use of
> > > > isolcpus= or cpuset isolated partitions.
> > > > 
> > > > And now HK_TYPE_DOMAIN includes all kinds of domain isolated CPUs.
> > > > 
> > > > This means that HK_TYPE_KERNEL_NOISE (of which HK_TYPE_TICK is only an
> > > > alias) is always a superset of HK_TYPE_DOMAIN.
> > > That may not be true. Users can still set "isolcpus=" and "nohz_full=" with
> > > disjoint set of CPUs whether cpuset is used for additional isolated CPUs or
> > > not.
> > There can be domain isolated CPU that are not nohz_full indeed. But OTOH nohz_full
> > CPUs that are not domain isolated don't make much sense. I know such settings
> > exist but it's usually a half working misconfiguration. I wish I had
> > forbidden that since the early days but this was from times when we didn't know
> > about all the potential usages.
> 
> The assumption is true for cpuset isolated partition, but users may still
> set conflicting nohz_full and isolcpus parameters by mistake. We should
> probably a warning if this happens and document that clearly to enforce such
> rule.

Good point, warning and documention should be a good start!

> 
> Cheers,
> Longman
> 

-- 
Frederic Weisbecker
SUSE Labs
Re: [PATCH 19/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated()
Posted by Waiman Long 1 month ago
On 9/2/25 10:28 AM, Waiman Long wrote:
>
> On 8/29/25 11:48 AM, Frederic Weisbecker wrote:
>> It doesn't make sense to use nohz_full without also isolating the
>> related CPUs from the domain topology, either through the use of
>> isolcpus= or cpuset isolated partitions.
>>
>> And now HK_TYPE_DOMAIN includes all kinds of domain isolated CPUs.
>>
>> This means that HK_TYPE_KERNEL_NOISE (of which HK_TYPE_TICK is only an
>> alias) is always a superset of HK_TYPE_DOMAIN.
>
> That may not be true. Users can still set "isolcpus=" and "nohz_full=" 
> with disjoint set of CPUs whether cpuset is used for additional 
> isolated CPUs or not.

Instead of "is always a superset", I would prefer to use "should always 
be a superset" as it is a recommendation but users can still violate it.

Cheers,
Longman
Re: [PATCH 19/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated()
Posted by Frederic Weisbecker 1 week, 3 days ago
Le Tue, Sep 02, 2025 at 11:48:16AM -0400, Waiman Long a écrit :
> 
> On 9/2/25 10:28 AM, Waiman Long wrote:
> > 
> > On 8/29/25 11:48 AM, Frederic Weisbecker wrote:
> > > It doesn't make sense to use nohz_full without also isolating the
> > > related CPUs from the domain topology, either through the use of
> > > isolcpus= or cpuset isolated partitions.
> > > 
> > > And now HK_TYPE_DOMAIN includes all kinds of domain isolated CPUs.
> > > 
> > > This means that HK_TYPE_KERNEL_NOISE (of which HK_TYPE_TICK is only an
> > > alias) is always a superset of HK_TYPE_DOMAIN.
> > 
> > That may not be true. Users can still set "isolcpus=" and "nohz_full="
> > with disjoint set of CPUs whether cpuset is used for additional isolated
> > CPUs or not.
> 
> Instead of "is always a superset", I would prefer to use "should always be a
> superset" as it is a recommendation but users can still violate it.

Good point!

> Cheers,
> Longman
> 

-- 
Frederic Weisbecker
SUSE Labs