Re: [PATCH] sched/cache: Check reduced capacity before alb_break_llc()

[Chen Yu <yu.c.chen@intel.com>]

On Thu, Oct 29, 2026 at 04:55:29PM +0800, Zhan Xusheng wrote:
> Hi Chenyu,
> 
> On Thu, Oct 29, 2026 at 04:18:32PM +0800, Chen Yu wrote:
> > Moving the capacity check earlier seems to completely ignore the
> > task's LLC preference. It seems to be a trade-off between choosing
> > CPU capacity and cache re-population on a remote LLC, and cross-LLC
> > access latency due to cross-LLC migration. I don't know which one has
> > more impact, it looks to be workload-specific. May I know which
> > benchmark/platform you used to find this issue? I'd like to launch
> > hackbench/tbench/schbenh/netperf(or yours) to evaluate the impact.
> 
> No benchmark, I found it reading the code and reproduced it in QEMU
> with -smp 4,sockets=2,cores=2 and IRQ_TIME_ACCOUNTING.  A module spends
> 600us of every 1ms in an hrtimer handler on CPU0, CPU1 runs a pinned
> busy loop, and the test process has one busy thread and one thread that
> only sleeps (cache aware scheduling skips single-threaded processes).
> It starts pinned to CPU0 and is then allowed on all CPUs.  I can send
> the module and the program.
> 
> The LLC preference is only overridden when the capacity check fires,
> which is the same condition as your reduced_cap_alb().
> 
> > May I know if the issue is because of the
> > if (env->src_rq->nr_running <= 1)
> > 	return true
> > in alb_break_llc()?
> 
> Yes.
> 
> > If yes, to mitigate the possible impact, do you think tuning the
> > alb_break_llc() would be safer?
> 
> I tried your two patches on the same setup.  The task still stays on
> CPU0 for the whole 20 seconds, at about 1.8e7 iterations/s against
> 4.6e7 with cache aware scheduling disabled.  Without the early return,
> alb_break_llc() falls through to can_migrate_llc(), which still
> forbids moving the task off its preferred LLC here.
>

It seems that can_migrate_llc() thinks a 60% IRQ pressure does not prevent
the task from being migrated away from its preferred LLC, because after moving
a task with 1024 util to LLC1, the remaining util still fits LLC0.

Suppose, before the migration check, in your scenario:
task p1 has util 1024 on CPU0, and task p2 has util 1024 on CPU1;
LLC0 cap = 1024 + 1024*0.4 = 1433  (IRQ pressure)
LLC1 cap = 2048

If p1 is moved from LLC0 to LLC1, the remaining util for LLC0 is 1024
(only p2's). Since 1024 < 1433 * 0.75 (fits_llc_capacity(src_util, src_cap)),
can_migrate_llc() returns mig_forbid.

That is to say, only if the IRQ pressure is above 66.7% in your test case does
fits_llc_capacity() return false, which allows the task migration.

Side note: while looking at fits_llc_capacity(), I found there might be a mismatch
in comparing a task's util and CPU capacity directly. The former is based on rq_clock_task,
which is transparent to IRQ pressure, while the latter is calculated from IRQ pressure,
comparing task util and CPU capacity is inaccurate. But since it is derived from
group_is_overloaded(), which already compares CPU capacity and task util, we can keep
it as it is until we see problems from this. After all, they are heuristic.

I'll run hackbench and netperf (which should trigger higher IRQ pressure). If there is
no issue, I think your original change is OK.

thanks,
Chenyu