From 0d6526f82c3cdefcca47f73f5fc08dc6f335eac6 Mon Sep 17 00:00:00 2001 From: Tim Chen Date: Mon, 21 Sep 2026 17:37:22 -0700 Subject: sched/cache: Keep nr_pref_llc_running in the runnable domain, to fix LLC mis-scheduling bug alb_break_llc() decides whether to break LLC preference during active load balance. It does so by testing that every runnable fair task on the source rq prefers its LLC: env->src_rq->nr_pref_llc_running == env->src_rq->cfs.h_nr_runnable But the two counters cover different sets. nr_pref_llc_running is updated in account_llc_enqueue()/account_llc_dequeue(), next to cfs_rq->nr_queued, so it follows queued tasks. h_nr_runnable is updated in set_delayed()/ clear_delayed() and drops delay-dequeued tasks. So under DELAY_DEQUEUE, a preferring task that goes to sleep stays counted in nr_pref_llc_running while h_nr_runnable falls. The equality then breaks, alb_break_llc() returns false, and active balance is free to pull a task off its preferred LLC. Active balance only moves runnable tasks, and this is the only LLC check it consults: once the stopper runs, LBF_ACTIVE_LB skips the per-task test in can_migrate_task(). The runnable set is the one we want. Fix it on the counter side. A task should be counted in nr_pref_llc_running exactly while it is both queued on its preferred LLC (pref_llc_queued) and runnable (!sched_delayed). Define that membership once in task_pref_llc_runnable(), and adjust the counter only through pref_llc_running_inc()/pref_llc_running_dec() from the four sites that change either input: account_llc_enqueue(), account_llc_dequeue(), set_delayed() and clear_delayed(). Gating every update on the same predicate keeps the delay, wake and dequeue paths from double-counting or underflowing; see the comments at those sites for the ordering. nr_llc_running and sd->llc_counts are not touched and stay on queued semantics. Fixes: 714059f79ff0 ("sched/cache: Handle moving single tasks to/from their preferred LLC") Closes: https://lore.kernel.org/lkml/20260827135000.735138-1-zhanxusheng@xiaomi.com/ Reported-by: Zhan Xusheng Suggested-by: Chen Yu Signed-off-by: Tim Chen Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Kayra Cizmeci Cc: # v7.2.x Link: https://patch.msgid.link/06af61afedac32e6477f57feb4d658f6c411c3af.1790035273.git.tim.c.chen@linux.intel.com --- Documentation/ABI/testing/debugfs-driver-dcc | 127 +++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 Documentation/ABI/testing/debugfs-driver-dcc (limited to 'Documentation/ABI/testing/debugfs-driver-dcc') diff --git a/Documentation/ABI/testing/debugfs-driver-dcc b/Documentation/ABI/testing/debugfs-driver-dcc new file mode 100644 index 000000000..27ed5919d --- /dev/null +++ b/Documentation/ABI/testing/debugfs-driver-dcc @@ -0,0 +1,127 @@ +What: /sys/kernel/debug/dcc/.../ready +Date: December 2022 +Contact: Souradeep Chowdhury +Description: + This file is used to check the status of the dcc + hardware if it's ready to receive user configurations. + A 'Y' here indicates dcc is ready. + +What: /sys/kernel/debug/dcc/.../trigger +Date: December 2022 +Contact: Souradeep Chowdhury +Description: + This is the debugfs interface for manual software + triggers. The trigger can be invoked by writing '1' + to the file. + +What: /sys/kernel/debug/dcc/.../config_reset +Date: December 2022 +Contact: Souradeep Chowdhury +Description: + This file is used to reset the configuration of + a dcc driver to the default configuration. When '1' + is written to the file, all the previous addresses + stored in the driver gets removed and users need to + reconfigure addresses again. + +What: /sys/kernel/debug/dcc/.../[list-number]/config +Date: December 2022 +Contact: Souradeep Chowdhury +Description: + This stores the addresses of the registers which + can be read in case of a hardware crash or manual + software triggers. The input addresses type + can be one of following dcc instructions: read, + write, read-write, and loop type. The lists need to + be configured sequentially and not in a overlapping + manner; e.g. users can jump to list x only after + list y is configured and enabled. The input format for + each type is as follows: + + i) Read instruction + + :: + + echo R >/sys/kernel/debug/dcc/../[list-number]/config + + where: + + + The address to be read. + + + The addresses word count, starting from address <1>. + Each word is 32 bits (4 bytes). If omitted, defaulted + to 1. + + + The bus type, which can be either 'apb' or 'ahb'. + The default is 'ahb' if leaved out. + + ii) Write instruction + + :: + + echo W > /sys/kernel/debug/dcc/../[list-number]/config + + where: + + + The address to be written. + + + The value to be written at . + + + The bus type, which can be either 'apb' or 'ahb'. + + iii) Read-write instruction + + :: + + echo RW > /sys/kernel/debug/dcc/../[list-number]/config + + where: + + + The address to be read and written. + + + The value to be written at . + + + The value mask. + + iv) Loop instruction + + :: + + echo L
... > /sys/kernel/debug/dcc/../[list-number]/config + + where: + + + Number of iterations + +
+ total number of addresses to be written + +
+ Space-separated list of addresses. + +What: /sys/kernel/debug/dcc/.../[list-number]/enable +Date: December 2022 +Contact: Souradeep Chowdhury +Description: + This debugfs interface is used for enabling the + the dcc hardware. A file named "enable" is in the + directory list number where users can enable/disable + the specific list by writing boolean (1 or 0) to the + file. + + On enabling the dcc, all the addresses specified + by the user for the corresponding list is written + into dcc sram which is read by the dcc hardware + on manual or crash induced triggers. Lists must + be configured and enabled sequentially, e.g. list + 2 can only be enabled when list 1 have so. -- cgit v1.3.1