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 --- drivers/gpio/TODO | 174 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 drivers/gpio/TODO (limited to 'drivers/gpio/TODO') diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO new file mode 100644 index 000000000..7ce80fde1 --- /dev/null +++ b/drivers/gpio/TODO @@ -0,0 +1,174 @@ +This is a place for planning the ongoing long-term work in the GPIO +subsystem. + +=============================================================================== + +GPIO descriptors + +Starting with commit 79a9becda894 the GPIO subsystem embarked on a journey +to move away from the global GPIO numberspace and toward a descriptor-based +approach. This means that GPIO consumers, drivers and machine descriptions +ideally have no use or idea of the global GPIO numberspace that has/was +used in the inception of the GPIO subsystem. + +The numberspace issue is the same as to why irq is moving away from irq +numbers to IRQ descriptors. + +The underlying motivation for this is that the GPIO numberspace has become +unmanageable: machine board files tend to become full of macros trying to +establish the numberspace at compile-time, making it hard to add any numbers +in the middle (such as if you missed a pin on a chip) without the numberspace +breaking. + +Machine descriptions such as device tree or ACPI does not have a concept of the +Linux GPIO number as those descriptions are external to the Linux kernel +and treat GPIO lines as abstract entities. + +The runtime-assigned GPIO numberspace (what you get if you assign the GPIO +base as -1 in struct gpio_chip) has also became unpredictable due to factors +such as probe ordering and the introduction of -EPROBE_DEFER making probe +ordering of independent GPIO chips essentially unpredictable, as their base +number will be assigned on a first come first serve basis. + +The best way to get out of the problem is to make the global GPIO numbers +unimportant by simply not using them. GPIO descriptors deal with this. + +Work items: + +- Convert all GPIO device drivers to only #include + +- Convert all consumer drivers to only #include + +- Convert all machine descriptors in "boardfiles" to only + #include , the other option being to convert it + to a machine description such as device tree, ACPI or fwnode that + implicitly does not use global GPIO numbers. + +- Fix drivers to not read back struct gpio_chip::base. Some drivers do + that and would be broken by attempts to poison it or make it dynamic. + Example in AT91 pinctrl driver: + https://lore.kernel.org/all/1d00c056-3d61-4c22-bedd-3bae0bf1ddc4@pengutronix.de/ + This particular driver is also DT-only, so with the above fixed, the + base can be made dynamic (set to -1) if CONFIG_GPIO_SYSFS is disabled. + +- When this work is complete (will require some of the items in the + following ongoing work as well) we can delete the old global + numberspace accessors from and eventually delete + altogether. + +------------------------------------------------------------------------------- + +Collect drivers + +Collect GPIO drivers from arch/* and other places that should be placed +in drivers/gpio/gpio-*. Augment platforms to create platform devices or +similar and probe a proper driver in the gpiolib subsystem. + +In some cases it makes sense to create a GPIO chip from the local driver +for a few GPIOs. Those should stay where they are. + +At the same time it makes sense to get rid of code duplication in existing or +new coming drivers. For example, gpio-ml-ioh should be incorporated into +gpio-pch. + +------------------------------------------------------------------------------- + +Generic MMIO GPIO + +The GPIO drivers can utilize the generic MMIO helper library in many +cases, and the helper library should be as helpful as possible for MMIO +drivers. (drivers/gpio/gpio-mmio.c) + +Work items: + +- Look over and identify any remaining easily converted drivers and + dry-code conversions to MMIO GPIO for maintainers to test + +- Expand the MMIO GPIO or write a new library for regmap-based I/O + helpers for GPIO drivers on regmap that simply use offsets + 0..n in some register to drive GPIO lines + +- Expand the MMIO GPIO or write a new library for port-mapped I/O + helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use + this with dry-coding and sending to maintainers to test + +------------------------------------------------------------------------------- + +Generic regmap GPIO + +In the very similar way to Generic MMIO GPIO convert the users which can +take advantage of using regmap over direct IO accessors. Note, even in +MMIO case the regmap MMIO with gpio-regmap.c is preferable over gpio-mmio.c. + +------------------------------------------------------------------------------- + +GPIOLIB irqchip + +The GPIOLIB irqchip is a helper irqchip for "simple cases" that should +try to cover any generic kind of irqchip cascaded from a GPIO. + +- Look over and identify any remaining easily converted drivers and + dry-code conversions to gpiolib irqchip for maintainers to test + +------------------------------------------------------------------------------- + +Moving over to immutable irq_chip structures + +Most of the gpio chips implementing interrupt support rely on gpiolib +intercepting some of the irq_chip callbacks, preventing the structures +from being made read-only and forcing duplication of structures that +should otherwise be unique. + +The solution is to call into the gpiolib code when needed (resource +management, enable/disable or unmask/mask callbacks), and to let the +core code know about that by exposing a flag (IRQCHIP_IMMUTABLE) in +the irq_chip structure. The irq_chip structure can then be made unique +and const. + +A small number of drivers have been converted (pl061, tegra186, msm, +amd, apple), and can be used as examples of how to proceed with this +conversion. Note that drivers using the generic irqchip framework +cannot be converted yet, but watch this space! + +------------------------------------------------------------------------------- + +Remove legacy sysfs features + +We have two parallel per-chip class devices and per-exported-line attribute +groups in sysfs. One is using the obsolete global GPIO numberspace and the +second relies on hardware offsets of pins within the chip. Remove the former +once user-space has switched to using the latter. + +------------------------------------------------------------------------------- + +Remove GPIOD_FLAGS_BIT_NONEXCLUSIVE + +GPIOs in the linux kernel are meant to be an exclusive resource. This means +that the GPIO descriptors (the software representation of the hardware concept) +are not reference counted and - in general - only one user at a time can +request a GPIO line and control its settings. The consumer API is designed +around full control of the line's state as evidenced by the fact that, for +instance, gpiod_set_value() does indeed drive the line as requested, instead +of bumping an enable counter of some sort. + +A problematic use-case for GPIOs is when two consumers want to use the same +descriptor independently. An example of such a user is the regulator subsystem +which may instantiate several struct regulator_dev instances containing +a struct device but using the same enable GPIO line. + +A workaround was introduced in the form of the GPIOD_FLAGS_BIT_NONEXCLUSIVE +flag but its implementation is problematic: it does not provide any +synchronization of usage nor did it introduce any enable count meaning the +non-exclusive users of the same descriptor will in fact "fight" for the +control over it. This flag should be removed and replaced with a better +solution, possibly based on the new power sequencing subsystem. + +------------------------------------------------------------------------------- + +Remove devm_gpiod_unhinge() + +devm_gpiod_unhinge() is provided as a way to transfer the ownership of managed +enable GPIOs to the regulator core. Rather than doing that however, we should +make it possible for the regulator subsystem to deal with GPIO resources the +lifetime of which it doesn't control as logically, a GPIO obtained by a caller +should also be freed by it. -- cgit v1.3.1