Re: [Patch v4 17/22] sched/cache: Avoid cache-aware scheduling for memory-heavy processes

[Jirka Hladky]

Hi Tim,

> Was THP enabled for the MG run?

Yes, set to [always], and the MG working set is essentially entirely
THP-backed: AnonHugePages 27,738,112 kB of Rss 27,748,260 kB
(99.96%), measured mid-run. That also explains a number we had not
reconciled: 3.3M pages migrated from ~20k hint faults (160:1) is
only possible with 512-page faults.

> In the third run, did grp->footprint become non-zero after the
> sweep completed at t=33s?

I had not measured footprint in that run, so I re-ran the combined
trace until a sweep completed (completion is stochastic on this
workload: 0 in three earlier 43-53s runs, 1 in a fourth, 1 in this
one, at t=37.6s of 43s). The moment the scan sequence advanced, all
64 tasks ran task_numa_placement() within ~4 ms, each adding ~105k
pages: grp->footprint went 0 -> 111,785 -> 215,225 -> ... -> ~6.7M
pages, i.e. about the full working set, crossing the 27.6k-page LLC
threshold at the second placement. The aggregation was withdrawn for
the remaining ~7 s of the run.

So: sweep cadence is the problem and the size estimate is not.
Agreed. Our point 3 (0.1-0.3% coverage) was wrong in the THP
reading: the fault count is small but each fault carries 512 pages,
and a completed sweep's estimate is accurate.

> I lean toward doing both: Fix 2 for the cadence, Fix 1 for NUMA
> balancing off and for the first sweep. Peter, is the RSS bound
> acceptable when it is used only as a gate and never as the estimate?

Both fixes look right to us. Fix 2's predicted trip point matches
our data nicely: 54 THP faults is well under a second of faulting
once scanning starts, which lines up with the ~1.8 s warm-up we
measured before grp->cpu settles. With Fix 2, the MG run would
likely never aggregate at all. Fix 1 closing the NUMA-balancing-off
gap is also what our numa_balancing=0 test argues for. From my
side, the RSS-as-gate-only framing answers the April objection: it
is never used as the estimate, only as the bound while no estimate
exists.

> Would you consider testing the patches when we post them?
> We will CC you.

Yes, absolutely! We would be glad to test them. Please count us
in as early testers.

One data point for the validation matrix: nr_running_avg is a
smoothed average (~89% of the busy threads in our MG runs), and the
threshold is 80% of the LLC's CPUs (115 on this server), so around
128 busy threads it sits right on the line and aggregation becomes
nondeterministic run to run. We need to keep test thread counts clear
of that zone on large-LLC parts.

Thanks again,
Jirka

On Sat, Nov 14, 2026 at 12:07 AM Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> wrote: