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

[Zhan Xusheng <zhanxusheng1024@gmail.com>]

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.

Thanks,
Zhan Xusheng