Hi Yangyu,

thanks very much for enhancing cache-aware scheduling,

On 7/22/2026 5:10 PM, Yangyu Chen wrote:
Cache aware scheduling is currently controlled only through global
debugfs knobs, but the right aggressiveness is workload and platform
specific. A multi-threaded Verilator run is one example: its RSS is
large while only a small part of it is hot, so an RSS-based footprint
estimate should not decide whether it is aggregated; and packing its
threads onto the SMT siblings of one LLC beats spreading them across
LLCs on some platforms (e.g. AMD EPYC Turin) but not on others (e.g.
EPYC Milan). Such choices cannot be made globally for the whole
machine. Add a prctl interface to override the knobs per process
(per mm_struct):

   prctl(PR_SCHED_CACHE, PR_SCHED_CACHE_SET, attr, value, 0);
   prctl(PR_SCHED_CACHE, PR_SCHED_CACHE_GET, attr, &value, 0);

A single prctl command implements both directions, like
PR_RSEQ_SLICE_EXTENSION. The attributes are a per-process enable
(effective only while the feature is globally active), the two
aggregation tolerances, the overaggr percentage (applied where a
task's own migration is admitted; group level statistics span many
processes and keep using the global value), and an inherit mask
selecting which attributes an mm created by execve() keeps. fork()
always inherits everything, and the mask itself lives on the
task_struct so it survives both, which lets a numactl-like launcher
configure a workload and exec it.

The overrides live in mm->sc_stat with -1 meaning "follow the global
default"; GET stores the raw value through an int pointer so this
sentinel round-trips without being mistaken for an errno.
mm_init_sched() gains the creating task to tell fork (p != current)
from exec (p == current) apart. A disabled mm has its preferred LLC
invalidated at the existing invalidation points, so all group-level
statistics self-neutralize.


We are working on a version that uses prctl to turn on/off/share
among tasks, which performs similar operations to core-scheduling
based on cookies[1]. That version decouples the mm from
cache-aware scheduling so that processes, tasks, or cgroups can
tag tasks with different "cookies". We are also exploring how to
leverage schedqos (from Qais) to take advantage of these
interfaces.

Your enhancement for tuning the parameters could be applied on top
of that, I suppose.

[1] https://github.com/chen-yu-surf/linux/commits/cache_aware_prctl_v1.4/

Reply via email to