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

[Zhan Xusheng <zhanxusheng1024@gmail.com>]

Hi Tim,

On Fri, 2026-10-30 at 16:24 -0700, Tim Chen wrote:
> 1) There could be other idle CPUs in the preferred LLC. It would be
> better for the task to move to one of them, through the idle balance
> on those CPUs (via same reduced capacity check), than to move to a non-preferred LLC now.

Right.  With CPU1 idle and 60% IRQ load on CPU0, mainline moved the
task to CPU1 in all 4 runs.  With the patch it went to CPU2, in the
other LLC, in 2 of 4.

> 2) There could be ping pong migrations.  Cache aware scheduling could 
> move the task back to the CPU, because with only IRQ load on it, that
> CPU is considered idle. I think this would also need to be dealt with.
>
> Could you check nr_migrations in /proc/<pid>/sched, or trace
> sched_migrate_task, over the 20 seconds on your setup
> before and after your patch?  A run with 20% to 40% irq load would also help.

It does ping-pong.  nr_migrations of the busy thread in the 19 s after
its affinity is widened, CPU1 busy, one value per run:

  IRQ load  mainline      patched             iterations/s
  20%       2, 6, 8, 20   8, 11, 12, 13       4.2e7 -> 5.2e7
  40%       0, 2, 2, 10   5, 9, 16, 43        3.1e7 -> 5.1e7
  60%       0, 0, 0, 16   7 to 36 (7 runs),   1.9e7 -> 5.0e7
                          327 (1 run)

At 60% the extra migrations come in bursts of 0->2 and 2->0 round
trips about 4 ms apart.  A kprobe on __active_load_balance_cpu_stop
shows the 2->0 moves run with LBF_ACTIVE_LB_LLC, so they are the cache
aware pull back, and the 0->2 moves are this patch.

So the override needs both of your conditions: no idle CPU in the
preferred LLC with more capacity, and no pull back onto a CPU whose
capacity is reduced.  I'll work on a v2 along those lines.

Thanks,
Zhan Xusheng