sched/cache: Keep nr_pref_llc_running in the runnable domain, to fix LLC mis-scheduling buggrafted

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 <zhanxusheng@xiaomi.com>
Suggested-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Cc: <stable@kernel.org> # v7.2.x
Link: https://patch.msgid.link/06af61afedac32e6477f57feb4d658f6c411c3af.1790035273.git.tim.c.chen@linux.intel.com

1 files changed, 196 insertions, 0 deletions

diff --git a/drivers/video/fbdev/valkyriefb.h b/drivers/video/fbdev/valkyriefb.h
new file mode 100644
index 000000000..bad24eec7
--- /dev/null
+++ b/drivers/video/fbdev/valkyriefb.h
@@ -0,0 +1,196 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * valkyriefb.h: Constants of all sorts for valkyriefb
+ *
+ *  Created 8 August 1998 by 
+ *  Martin Costabel <costabel@wanadoo.fr> and Kevin Schoedel
+ *
+ * Vmode-switching changes and vmode 15/17 modifications created 29 August
+ * 1998 by Barry K. Nathan <barryn@pobox.com>.
+ * 
+ * vmode 10 changed by Steven Borley <sjb@salix.demon.co.uk>, 14 mai 2000
+ *
+ * Ported to 68k Macintosh by David Huggins-Daines <dhd@debian.org>
+ *
+ * Based directly on:
+ *
+ *  controlfb.h: Constants of all sorts for controlfb
+ *  Copyright (C) 1998 Daniel Jacobowitz <dan@debian.org>
+ *
+ *  pmc-valkyrie.h: Console support for PowerMac "control" display adaptor.
+ *  Copyright (C) 1997 Paul Mackerras.
+ *
+ *  pmc-valkyrie.c: Console support for PowerMac "control" display adaptor.
+ *  Copyright (C) 1997 Paul Mackerras.
+ *
+ * and indirectly from:
+ *
+ *  pmc-control.h: Console support for PowerMac "control" display adaptor.
+ *  Copyright (C) 1997 Paul Mackerras.
+ *
+ *  pmc-control.c: Console support for PowerMac "control" display adaptor.
+ *  Copyright (C) 1996 Paul Mackerras.
+ *
+ *  platinumfb.c: Console support for PowerMac "platinum" display adaptor.
+ *  Copyright (C) 1998 Jon Howell
+ */
+
+#ifdef CONFIG_MAC
+/* Valkyrie registers are word-aligned on m68k */
+#define VALKYRIE_REG_PADSIZE	3
+#else
+#define VALKYRIE_REG_PADSIZE	7
+#endif
+
+/*
+ * Structure of the registers for the Valkyrie colormap registers.
+ */
+struct cmap_regs {
+	unsigned char addr;
+	char pad1[VALKYRIE_REG_PADSIZE];
+	unsigned char lut;
+};
+
+/*
+ * Structure of the registers for the "valkyrie" display adaptor.
+ */
+
+struct vpreg {			/* padded register */
+	unsigned char r;
+	char pad[VALKYRIE_REG_PADSIZE];
+};
+
+
+struct valkyrie_regs {
+	struct vpreg mode;
+	struct vpreg depth;
+	struct vpreg status;
+	struct vpreg reg3;
+	struct vpreg intr;
+	struct vpreg reg5;
+	struct vpreg intr_enb;
+	struct vpreg msense;
+};
+
+/*
+ * Register initialization tables for the valkyrie display.
+ *
+ * Dot clock rate is
+ * 3.9064MHz * 2**clock_params[2] * clock_params[1] / clock_params[0].
+ */
+struct valkyrie_regvals {
+	unsigned char mode;
+	unsigned char clock_params[3];
+	int	pitch[2];		/* bytes/line, indexed by color_mode */
+	int	hres;
+	int	vres;
+};
+
+#ifndef CONFIG_MAC
+/* Register values for 1024x768, 75Hz mode (17) */
+/* I'm not sure which mode this is (16 or 17), so I'm defining it as 17,
+ * since the equivalent mode in controlfb (which I adapted this from) is
+ * also 17. Just because MacOS can't do this on Valkyrie doesn't mean we
+ * can't! :)
+ *
+ * I was going to use 12, 31, 3, which I found by myself, but instead I'm
+ * using 11, 28, 3 like controlfb, for consistency's sake.
+ */
+
+static struct valkyrie_regvals valkyrie_reg_init_17 = {
+    15, 
+    { 11, 28, 3 },  /* pixel clock = 79.55MHz for V=74.50Hz */
+    { 1024, 0 },
+	1024, 768
+};
+
+/* Register values for 1024x768, 72Hz mode (15) */
+/* This used to be 12, 30, 3 for pixel clock = 78.12MHz for V=72.12Hz, but
+ * that didn't match MacOS in the same video mode on this chip, and it also
+ * caused the 15" Apple Studio Display to not work in this mode. While this
+ * mode still doesn't match MacOS exactly (as far as I can tell), it's a lot
+ * closer now, and it works with the Apple Studio Display.
+ *
+ * Yes, even though MacOS calls it "72Hz", in reality it's about 70Hz.
+ */
+static struct valkyrie_regvals valkyrie_reg_init_15 = {
+    15,
+    { 12, 29, 3 },  /* pixel clock = 75.52MHz for V=69.71Hz? */
+		    /* I interpolated the V=69.71 from the vmode 14 and old 15
+		     * numbers. Is this result correct?
+		     */
+    { 1024, 0 },
+	1024, 768
+};
+
+/* Register values for 1024x768, 60Hz mode (14) */
+static struct valkyrie_regvals valkyrie_reg_init_14 = {
+    14,
+    { 15, 31, 3 },  /* pixel clock = 64.58MHz for V=59.62Hz */
+    { 1024, 0 },
+	1024, 768
+};
+#endif /* !defined CONFIG_MAC */
+
+/* Register values for 832x624, 75Hz mode (13) */
+static struct valkyrie_regvals valkyrie_reg_init_13 = {
+    9,
+    { 23, 42, 3 },  /* pixel clock = 57.07MHz for V=74.27Hz */
+    { 832, 0 },
+	832, 624
+};
+
+/* Register values for 800x600, 72Hz mode (11) */
+static struct valkyrie_regvals valkyrie_reg_init_11 = {
+    13,
+    { 17, 27, 3 },  /* pixel clock = 49.63MHz for V=71.66Hz */
+    { 800, 0 },
+	800, 600
+};
+
+/* Register values for 800x600, 60Hz mode (10) */
+static struct valkyrie_regvals valkyrie_reg_init_10 = {
+    12,
+    { 25, 32, 3 },  /* pixel clock = 40.0015MHz,
+                     used to be 20,53,2, pixel clock 41.41MHz for V=59.78Hz */
+    { 800, 1600 },
+	800, 600
+};
+
+/* Register values for 640x480, 67Hz mode (6) */
+static struct valkyrie_regvals valkyrie_reg_init_6 = {
+    6,
+    { 14, 27, 2 },  /* pixel clock = 30.13MHz for V=66.43Hz */
+    { 640, 1280 },
+	640, 480
+};
+
+/* Register values for 640x480, 60Hz mode (5) */
+static struct valkyrie_regvals valkyrie_reg_init_5 = {
+    11,
+    { 23, 37, 2 },  /* pixel clock = 25.14MHz for V=59.85Hz */
+    { 640, 1280 },
+	640, 480
+};
+
+static struct valkyrie_regvals *valkyrie_reg_init[VMODE_MAX] = {
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	&valkyrie_reg_init_5,
+	&valkyrie_reg_init_6,
+	NULL,
+	NULL,
+	NULL,
+	&valkyrie_reg_init_10,
+	&valkyrie_reg_init_11,
+	NULL,
+	&valkyrie_reg_init_13,
+#ifndef CONFIG_MAC
+	&valkyrie_reg_init_14,
+	&valkyrie_reg_init_15,
+	NULL,
+	&valkyrie_reg_init_17,
+#endif
+};