[PATCH] sched/cache: Don't use fits_capacity() to compare thread and CPU counts

[PATCH] sched/cache: Don't use fits_capacity() to compare thread and CPU counts

[Zhan Xusheng]

From: Zhan Xusheng <zhanxusheng@xiaomi.com>

invalid_llc_nr() uses fits_capacity() to compare a thread count with a
CPU count, only for its 20% margin.  Qais's series changes
fits_capacity() to take a CPU number as its second argument, and this
call would then pass the CPU count as a CPU number without a warning.

Give the check its own helper.  x * 5 < y * 4 is the same comparison as
x * 1280 < y * 1024, so there is no functional change.

Link: https://lore.kernel.org/all/20260504020003.71306-5-qyousef@layalina.io/
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
---
This keeps the 20% margin.  Qais would rather not add hardcoded
margins, and llc_aggr_tolerance already scales the LLC size here, so
the margin could go, but that changes when a process stops being
aggregated.  Tim, Chen Yu, would you drop it?

 kernel/sched/fair.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index cfc982205b98..dfd6528d18ee 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1469,6 +1469,12 @@ static bool exceed_llc_capacity(struct sched_cache_group *grp, int cpu)
 	return false;
 }
 
+/* Are the running threads (in SMT siblings) below ~80% of the LLC's CPUs? */
+static inline bool fits_llc_nr(u64 nr_threads, unsigned int nr_cpus)
+{
+	return nr_threads * 5 < (u64)nr_cpus * 4;
+}
+
 static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
 			   int cpu)
 {
@@ -1485,8 +1491,8 @@ static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
 	if (scale == INT_MAX)
 		return false;
 
-	return !fits_capacity((READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads),
-			(scale * per_cpu(sd_llc_size, cpu)));
+	return !fits_llc_nr(READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads,
+			    scale * per_cpu(sd_llc_size, cpu));
 }
 
 /*

base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8
-- 
2.43.0

Re: [PATCH] sched/cache: Don't use fits_capacity() to compare thread and CPU counts

[Qais Yousef]

On 11/2/26 02:15, Zhan Xusheng wrote:
> From: Zhan Xusheng <zhanxusheng@xiaomi.com>
> 
> invalid_llc_nr() uses fits_capacity() to compare a thread count with a
> CPU count, only for its 20% margin.  Qais's series changes
> fits_capacity() to take a CPU number as its second argument, and this
> call would then pass the CPU count as a CPU number without a warning.
> 
> Give the check its own helper.  x * 5 < y * 4 is the same comparison as
> x * 1280 < y * 1024, so there is no functional change.
> 
> Link: https://lore.kernel.org/all/20260504020003.71306-5-qyousef@layalina.io/
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>

Thanks for the patch. LGTM, although I hope we can do better.

Reviewed-by: Qais Yousef <qyousef@layalina.io>

> ---
> This keeps the 20% margin.  Qais would rather not add hardcoded
> margins, and llc_aggr_tolerance already scales the LLC size here, so
> the margin could go, but that changes when a process stops being
> aggregated.  Tim, Chen Yu, would you drop it?

Tim, Chen,

From capacity comparisons, we had issues that we move too slowly or too fast in
some cases, that's why I was trying to remove this magic number.

I'd be surprised if this gives a global win.

Is this the best we can do? What is the problem you're working around here?

I see we have other magic like llc_aggr_tolerance and llc_imb_pct etc.

> 
>  kernel/sched/fair.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index cfc982205b98..dfd6528d18ee 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1469,6 +1469,12 @@ static bool exceed_llc_capacity(struct sched_cache_group *grp, int cpu)
>  	return false;
>  }
>  
> +/* Are the running threads (in SMT siblings) below ~80% of the LLC's CPUs? */
> +static inline bool fits_llc_nr(u64 nr_threads, unsigned int nr_cpus)
> +{
> +	return nr_threads * 5 < (u64)nr_cpus * 4;
> +}
> +
>  static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
>  			   int cpu)
>  {
> @@ -1485,8 +1491,8 @@ static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
>  	if (scale == INT_MAX)
>  		return false;
>  
> -	return !fits_capacity((READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads),
> -			(scale * per_cpu(sd_llc_size, cpu)));
> +	return !fits_llc_nr(READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads,
> +			    scale * per_cpu(sd_llc_size, cpu));
>  }
>  
>  /*
> 
> base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8

Re: [PATCH] sched/cache: Don't use fits_capacity() to compare thread and CPU counts

[Chen Yu]

Hi Qais,

On Tue, Nov 03, 2026 at 01:31:17AM +0000, Qais Yousef wrote:
> On 11/2/26 02:15, Zhan Xusheng wrote:
> > From: Zhan Xusheng <zhanxusheng@xiaomi.com>
> > 
> > invalid_llc_nr() uses fits_capacity() to compare a thread count with a
> > CPU count, only for its 20% margin.  Qais's series changes
> > fits_capacity() to take a CPU number as its second argument, and this
> > call would then pass the CPU count as a CPU number without a warning.
> > 
> > Give the check its own helper.  x * 5 < y * 4 is the same comparison as
> > x * 1280 < y * 1024, so there is no functional change.
> > 
> > Link: https://lore.kernel.org/all/20260504020003.71306-5-qyousef@layalina.io/
> > Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> 
> Thanks for the patch. LGTM, although I hope we can do better.
> 
> Reviewed-by: Qais Yousef <qyousef@layalina.io>
> 
> > ---
> > This keeps the 20% margin.  Qais would rather not add hardcoded
> > margins, and llc_aggr_tolerance already scales the LLC size here, so
> > the margin could go, but that changes when a process stops being
> > aggregated.  Tim, Chen Yu, would you drop it?
> 
> Tim, Chen,
> 
> From capacity comparisons, we had issues that we move too slowly or too fast in
> some cases, that's why I was trying to remove this magic number.
> 
> I'd be surprised if this gives a global win.
> 
> Is this the best we can do? What is the problem you're working around here?
> 
> I see we have other magic like llc_aggr_tolerance and llc_imb_pct etc.
>

The original idea was to avoid threads overaggregating on their preferred LLC.
There are several metrics used to avoid this overaggregation: the first one is
utilization, the second one is the number of active threads, and the third one
is the LLC cache size.

1. llc_overaggr_pct is used for utilization. The default value is 50%, which means
that if the utilization of the preferred LLC exceeds 50%, we slow down the aggregation.

2. invalid_llc_nr() leverages fits_capacity() to skip any process that has too many
active threads, and we don't want it to become saturated because every CPU in this LLC
has one runnable thread. fits_capacity() was reused only because it happened to be a good
fit for this case, and we don't want introduce extra tuning knobs like llc_overaggr_pct,
so 80% was chosen simply because fits_capacity() uses that value.

2. exceed_llc_capacity() checks whether a task's memory footprint exceeds the LLC cache
size. This is where llc_aggr_tolerance is involved.

So for 1, 2, and 3, they address different aspects that prevent overaggregation. We can not
simply remove one of them and let the rest avoid overaggregation. For example, the process
might have very low utilization (frequently doing context switch) but have a large number of
active threads. In this case, we don't want to do aggregation for this process.

After the fine-grained control cache-aware scheduling is introduced, we allow the user tune
these parameters per group aggressively. But for the global settings, we don't want to bring
any performance regression, so these parameters are just safeguards for a global conservative
strategy. 

For Xusheng's patch, it looks good to me at the moment.

thanks,
Chenyu


> > 
> >  kernel/sched/fair.c | 10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index cfc982205b98..dfd6528d18ee 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -1469,6 +1469,12 @@ static bool exceed_llc_capacity(struct sched_cache_group *grp, int cpu)
> >  	return false;
> >  }
> >  
> > +/* Are the running threads (in SMT siblings) below ~80% of the LLC's CPUs? */
> > +static inline bool fits_llc_nr(u64 nr_threads, unsigned int nr_cpus)
> > +{
> > +	return nr_threads * 5 < (u64)nr_cpus * 4;
> > +}
> > +
> >  static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
> >  			   int cpu)
> >  {
> > @@ -1485,8 +1491,8 @@ static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
> >  	if (scale == INT_MAX)
> >  		return false;
> >  
> > -	return !fits_capacity((READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads),
> > -			(scale * per_cpu(sd_llc_size, cpu)));
> > +	return !fits_llc_nr(READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads,
> > +			    scale * per_cpu(sd_llc_size, cpu));
> >  }
> >  
> >  /*
> > 
> > base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8
> 

Re: [PATCH] sched/cache: Don't use fits_capacity() to compare thread and CPU counts

[Chen Yu]

Hi Xusheng,

On Mon, Nov 02, 2026 at 10:15:36AM +0800, Zhan Xusheng wrote:
> From: Zhan Xusheng <zhanxusheng@xiaomi.com>
> 
> invalid_llc_nr() uses fits_capacity() to compare a thread count with a
> CPU count, only for its 20% margin.  Qais's series changes
> fits_capacity() to take a CPU number as its second argument, and this
> call would then pass the CPU count as a CPU number without a warning.
> 
> Give the check its own helper.  x * 5 < y * 4 is the same comparison as
> x * 1280 < y * 1024, so there is no functional change.
> 
> Link: https://lore.kernel.org/all/20260504020003.71306-5-qyousef@layalina.io/
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> ---
> This keeps the 20% margin.  Qais would rather not add hardcoded
> margins, and llc_aggr_tolerance already scales the LLC size here, so
> the margin could go, but that changes when a process stops being
> aggregated.  Tim, Chen Yu, would you drop it?
> 

As replied to Qais in another thread, I'm not sure llc_aggr_tolerance
can cover the thread number case, as the former is only for LLC size
scaling,

for this patch,

Reviewed-by: Chen Yu <yu.c.chen@intel.com>

thanks,
Chenyu

>  kernel/sched/fair.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index cfc982205b98..dfd6528d18ee 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1469,6 +1469,12 @@ static bool exceed_llc_capacity(struct sched_cache_group *grp, int cpu)
>  	return false;
>  }
>  
> +/* Are the running threads (in SMT siblings) below ~80% of the LLC's CPUs? */
> +static inline bool fits_llc_nr(u64 nr_threads, unsigned int nr_cpus)
> +{
> +	return nr_threads * 5 < (u64)nr_cpus * 4;
> +}
> +
>  static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
>  			   int cpu)
>  {
> @@ -1485,8 +1491,8 @@ static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
>  	if (scale == INT_MAX)
>  		return false;
>  
> -	return !fits_capacity((READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads),
> -			(scale * per_cpu(sd_llc_size, cpu)));
> +	return !fits_llc_nr(READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads,
> +			    scale * per_cpu(sd_llc_size, cpu));
>  }
>  
>  /*
> 
> base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8
> -- 
> 2.43.0
> 

Re: [PATCH] sched/cache: Don't use fits_capacity() to compare thread and CPU counts

[Tim Chen]

On Mon, 2026-11-02 at 10:15 +0800, Zhan Xusheng wrote:
> From: Zhan Xusheng <zhanxusheng@xiaomi.com>
> 
> invalid_llc_nr() uses fits_capacity() to compare a thread count with a
> CPU count, only for its 20% margin.  Qais's series changes
> fits_capacity() to take a CPU number as its second argument, and this
> call would then pass the CPU count as a CPU number without a warning.
> 
> Give the check its own helper.  x * 5 < y * 4 is the same comparison as
> x * 1280 < y * 1024, so there is no functional change.
> 
> Link: https://lore.kernel.org/all/20260504020003.71306-5-qyousef@layalina.io/
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> ---
> This keeps the 20% margin.  Qais would rather not add hardcoded
> margins, and llc_aggr_tolerance already scales the LLC size here, so
> the margin could go, but that changes when a process stops being
> aggregated.  Tim, Chen Yu, would you drop it?


Xusheng,

We tune the system based on a default llc_aggr_tolerance of 1,
where the number of running threads is 80% of the number of cores,
to prevent over-subscription which could lead to regressions.

This 80% factor is leaning on the conservative side to prevent
regressions for workloads where cache aware scheduling may
not help on multi-threaded process with little shared data.

We set the llc_aggr_tolerance as a default of 1 for more intuitive
tuning.  It varies from 

0 (no aggregation), 
1 (default with conservative aggregation)
100 (always aggregate)

Hope that makes sense.

Otherwise, the patch looks good to me.

Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>

Tim

> 
>  kernel/sched/fair.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index cfc982205b98..dfd6528d18ee 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1469,6 +1469,12 @@ static bool exceed_llc_capacity(struct sched_cache_group *grp, int cpu)
>  	return false;
>  }
>  
> +/* Are the running threads (in SMT siblings) below ~80% of the LLC's CPUs? */
> +static inline bool fits_llc_nr(u64 nr_threads, unsigned int nr_cpus)
> +{
> +	return nr_threads * 5 < (u64)nr_cpus * 4;
> +}
> +
>  static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
>  			   int cpu)
>  {
> @@ -1485,8 +1491,8 @@ static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
>  	if (scale == INT_MAX)
>  		return false;
>  
> -	return !fits_capacity((READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads),
> -			(scale * per_cpu(sd_llc_size, cpu)));
> +	return !fits_llc_nr(READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads,
> +			    scale * per_cpu(sd_llc_size, cpu));
>  }
>  
>  /*
> 
> base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8

Re: [PATCH] sched/cache: Don't use fits_capacity() to compare thread and CPU counts

[Tim Chen]

On Mon, 2026-11-02 at 10:15 +0800, Zhan Xusheng wrote:
> From: Zhan Xusheng <zhanxusheng@xiaomi.com>
> 
> invalid_llc_nr() uses fits_capacity() to compare a thread count with a
> CPU count, only for its 20% margin.  Qais's series changes
> fits_capacity() to take a CPU number as its second argument, and this
> call would then pass the CPU count as a CPU number without a warning.
> 
> Give the check its own helper.  x * 5 < y * 4 is the same comparison as
> x * 1280 < y * 1024, so there is no functional change.
> 
> Link: https://lore.kernel.org/all/20260504020003.71306-5-qyousef@layalina.io/
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> ---
> This keeps the 20% margin.  Qais would rather not add hardcoded
> margins, and llc_aggr_tolerance already scales the LLC size here, so
> the margin could go, but that changes when a process stops being
> aggregated.  Tim, Chen Yu, would you drop it?
> 
>  kernel/sched/fair.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index cfc982205b98..dfd6528d18ee 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1469,6 +1469,12 @@ static bool exceed_llc_capacity(struct sched_cache_group *grp, int cpu)
>  	return false;
>  }
>  
> +/* Are the running threads (in SMT siblings) below ~80% of the LLC's CPUs? */

BTW, it will be more accurate to say

/* Number of running threads below 80% of LLC's cores for default setting */

Tim

> +static inline bool fits_llc_nr(u64 nr_threads, unsigned int nr_cpus)
> +{
> +	return nr_threads * 5 < (u64)nr_cpus * 4;
> +}
> +
>  static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
>  			   int cpu)
>  {
> @@ -1485,8 +1491,8 @@ static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
>  	if (scale == INT_MAX)
>  		return false;
>  
> -	return !fits_capacity((READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads),
> -			(scale * per_cpu(sd_llc_size, cpu)));
> +	return !fits_llc_nr(READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads,
> +			    scale * per_cpu(sd_llc_size, cpu));
>  }
>  
>  /*
> 
> base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8

Re: [PATCH] sched/cache: Don't use fits_capacity() to compare thread and CPU counts

[Tim Chen]

On Tue, 2026-11-03 at 01:31 +0000, Qais Yousef wrote:
> On 11/2/26 02:15, Zhan Xusheng wrote:
> > From: Zhan Xusheng <zhanxusheng@xiaomi.com>
> > 
> > invalid_llc_nr() uses fits_capacity() to compare a thread count with a
> > CPU count, only for its 20% margin.  Qais's series changes
> > fits_capacity() to take a CPU number as its second argument, and this
> > call would then pass the CPU count as a CPU number without a warning.
> > 
> > Give the check its own helper.  x * 5 < y * 4 is the same comparison as
> > x * 1280 < y * 1024, so there is no functional change.
> > 
> > Link: https://lore.kernel.org/all/20260504020003.71306-5-qyousef@layalina.io/
> > Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> 
> Thanks for the patch. LGTM, although I hope we can do better.
> 
> Reviewed-by: Qais Yousef <qyousef@layalina.io>
> 
> > ---
> > This keeps the 20% margin.  Qais would rather not add hardcoded
> > margins, and llc_aggr_tolerance already scales the LLC size here, so
> > the margin could go, but that changes when a process stops being
> > aggregated.  Tim, Chen Yu, would you drop it?
> 
> Tim, Chen,
> 
> From capacity comparisons, we had issues that we move too slowly or too fast in
> some cases, that's why I was trying to remove this magic number.
> 
> I'd be surprised if this gives a global win.
> 
> Is this the best we can do? What is the problem you're working around here?

Qais,

The 20% margin is a deliberately conservative margin for the default
llc_aggr_tolerance. With no knowledge of whether a process's threads
share data, we only aggregate a process when its threads fit well within
the cores of one LLC, so workloads that don't benefit from aggregation
are not hurt by packing them into a single LLC.

Where aggregation is known to help, the user should raise
llc_aggr_tolerance (or, later, use hints like schedqos or the prctl
interface we proposed) rather than rely on a smaller margin. The
tolerance scales the limit (0.8x cores at the default, 1.6x at 2, and so
on), so the margin only sets how conservative the starting point is.

Thanks.

Tim 

> 
> I see we have other magic like llc_aggr_tolerance and llc_imb_pct etc.
> 
> > 
> >  kernel/sched/fair.c | 10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index cfc982205b98..dfd6528d18ee 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -1469,6 +1469,12 @@ static bool exceed_llc_capacity(struct sched_cache_group *grp, int cpu)
> >  	return false;
> >  }
> >  
> > +/* Are the running threads (in SMT siblings) below ~80% of the LLC's CPUs? */
> > +static inline bool fits_llc_nr(u64 nr_threads, unsigned int nr_cpus)
> > +{
> > +	return nr_threads * 5 < (u64)nr_cpus * 4;
> > +}
> > +
> >  static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
> >  			   int cpu)
> >  {
> > @@ -1485,8 +1491,8 @@ static bool invalid_llc_nr(struct sched_cache_group *grp, struct task_struct *p,
> >  	if (scale == INT_MAX)
> >  		return false;
> >  
> > -	return !fits_capacity((READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads),
> > -			(scale * per_cpu(sd_llc_size, cpu)));
> > +	return !fits_llc_nr(READ_ONCE(grp->nr_running_avg) * cpu_smt_num_threads,
> > +			    scale * per_cpu(sd_llc_size, cpu));
> >  }
> >  
> >  /*
> > 
> > base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8
>