* [PATCH RFC v6 00/18] riscv: add Ssqosid and CBQRI resctrl support
From: Drew Fustini @ 2026-06-01 20:35 UTC (permalink / raw)
To: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Radim Krčmář, Samuel Holland, Adrien Ricciardi,
Nicolas Pitre, Kornel Dulęba, Atish Patra, Atish Kumar Patra,
Vasudevan Srinivasan, Ved Shanbhogue, Conor Dooley, yunhui cui,
Chen Pei, Liu Zhiwei, Weiwei Li, guo.wenjia23, Gong Shuai,
Gong Shuai, liu.qingtao2, Reinette Chatre, Tony Luck, Babu Moger,
Peter Newman, Fenghua Yu, James Morse, Ben Horgan, Dave Martin,
Rob Herring, Conor Dooley, Krzysztof Kozlowski, Rafael J. Wysocki,
Len Brown, Robert Moore, Sunil V L, Drew Fustini, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
Jonathan Corbet
Cc: linux-kernel, linux-riscv, x86, linux-acpi, acpica-devel,
devicetree, Paul Walmsley, Conor Dooley, linux-rt-devel,
linux-doc
This RFC series adds RISC-V QoS support: the Ssqosid extension [1]
(srmcfg CSR), the CBQRI controller interface [2] integrated with
resctrl [3], and ACPI RQSC [4] for controller discovery. DT support
is possible but no platform drivers are included. The series is
also available as a branch [5].
QEMU support for Ssqosid and CBQRI lives in [6], with ACPI RQSC as
a follow-on series [7]. There is also a combined branch [8].
Series organization
-------------------
01 DT binding for Ssqosid extension
02-03 Ssqosid ISA support (detection, srmcfg CSR, switch_to)
04-06 fs/resctrl helpers and resource type additions
07-10 CBQRI device ops (cbqri_devices.c): capacity probe +
allocation, capacity monitoring, bandwidth probe +
allocation, bandwidth monitoring
11-15 CBQRI resctrl integration (cbqri_resctrl.c): cache
allocation, L3 cache occupancy monitoring, MB_MIN
bandwidth allocation, MB_WGHT bandwidth allocation,
mbm_total_bytes monitoring
16-17 ACPI RQSC parser and init
18 Enable resctrl filesystem for Ssqosid (Kconfig)
Refer to the v3 cover letter [9] for the test setup including the
reference SoC layout and the corresponding QEMU command line.
[1] https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0
[2] https://github.com/riscv-non-isa/riscv-cbqri/releases/tag/v1.0
[3] https://docs.kernel.org/filesystems/resctrl.html
[4] https://github.com/riscv-non-isa/riscv-rqsc/blob/main/src/
[5] https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git/log/?h=b4/ssqosid-cbqri-rqsc
[6] https://lore.kernel.org/qemu-devel/20260105-riscv-ssqosid-cbqri-v4-0-9ad7671dde78@kernel.org/
[7] https://lore.kernel.org/qemu-devel/20260202-riscv-rqsc-v1-0-dcf448a3ed73@kernel.org/
[8] https://github.com/tt-fustini/qemu/tree/b4/riscv-rqsc
[9] https://lore.kernel.org/r/20260414-ssqosid-cbqri-rqsc-v7-0-v3-0-b3b2e7e9847a@kernel.org
Key design decisions
--------------------
- Create new resource types as RDT_RESOURCE_MBA cannot represent the
semantics of the CBQRI bandwidth controllers:
- RDT_RESOURCE_MB_MIN matches CBQRI Rbwb (reserved bandwidth
blocks). The sum of Rbwb across all control groups must be
<= MRBWB (maximum number of reserved bandwidth blocks).
- RDT_RESOURCE_MB_WGHT matches CBQRI Mweight, the weighted share of
the remaining bandwidth blocks. Values are in [0, 255]: 0 disables
work-conserving sharing for the group, 1..255 compete for the
leftover pool.
- mbm_total_bytes is supported only when the platform exposes exactly
one mon-capable bandwidth controller and exactly one L3 domain.
Pairing a single BC across multiple L3 domains would let standard
userspace tools overcount system bandwidth by summing the same
counter across domains.
Open issues
-----------
- RDT_RESOURCE_MB_MIN and RDT_RESOURCE_MB_WGHT are intended to drive
discussion, not as the final solution. Reinette has recently posted
a generic schema proof of concept. I will based the next revision on
that.
- resctrl monitoring scope limitations:
- monitor-only L3 capacity controllers are not supported.
- CBQRI capacity controllers can monitor any cache level, but resctrl
only supports occupancy on L3.
- resctrl needs to gain a non-CPU scope level for mbm_total_bytes
to be supported on platforms with multiple bandwidth controllers
or multiple L3 domains.
- When a control group is freed, rbwb_cache[closid] is not reset,
so the MB_MIN sum check can count the stale reservation against
MRBWB. Fixing this requires a new resctrl_arch_* callback in
fs/resctrl invoked on group destroy, which is out of scope for
this arch-driver series.
- cc_cunits is not supported. cc_block_mask maps well onto resctrl's
existing CBM schema, but there is no existing equivalent for
capacity units.
- RQSC structs live in drivers/acpi/riscv/rqsc.h until the spec is
ratified and the ACPICA upstream submission lands. They will then move
to include/acpi/actbl2.h. The spec is in the final phase
before ratification.
Changes in v6:
--------------
The changes in this revision are based on the feedback in the Sashiko
review of v5 and Sunil V L's review of the RQSC parser.
riscv_cbqri device:
- Widen the remaining CBQRI_CONTROL_REGISTERS_OP/AT/RCID and the RBWB /
MWEIGHT field masks to GENMASK_ULL, so FIELD_MODIFY and ~mask on a
u64 register stay correct if RV32 support is ever added.
- Reject an rcid_count or mcid_count larger than 12-bits can encode.
- Probe monitoring with CONFIG_EVENT and a probe-safe event id rather
than READ_COUNTER. Run the AT probe only for allocation registers
- cbqri_bc_alloc_op() clears AT, matching the capacity path.
- cbqri_apply_bc_field() waits for BUSY=0 before staging the new value
so an in-flight op cannot consume a half-updated register.
- cbqri_read_rbwb() and cbqri_read_mweight() stage a sentinel in the
unread field, so a silent READ_LIMIT no-op is detected instead of
returning stale data.
resctrl:
- cbqri_resctrl_online_cpu() and cbqri_resctrl_offline_cpu() seed the
per-CPU default RCID/MCID.
- Partial attach failure detaches the CPU from every domain it reached.
- resctrl_arch_reset_rmid() no longer re-arms occupancy. Occupancy
counters are armed once and run free.
- The BC is paired and initialized only when mbm_total_bytes is enabled,
so a controller left unpicked on a system with multiple L3 domains
is not allocated and no longer clamps the occupancy rmid space.
- num_rmid is reported as the system-wide minimum mcid_count.
ACPI:
- Skip controllers whose RCID Count and MCID Count are both zero, as
RQSC requires at least one to be non-zero.
- Add the Memory-Side Cache, ACPI device and PCI device resource id
type constants.
Sashiko review:
https://sashiko.dev/#/patchset/20260524-ssqosid-cbqri-rqsc-v7-0-v5-0-78d3a7ba9dbe%40kernel.org
Link to v5:
https://lore.kernel.org/all/20260524-ssqosid-cbqri-rqsc-v7-0-v5-0-78d3a7ba9dbe@kernel.org/
Changes in v5:
--------------
The changes in this revision are based on the feedback in the Sashiko
review of the series.
Ssqosid:
- Seed cpu_srmcfg to U32_MAX in DEFINE_PER_CPU so early-boot context
switches always write the CSR rather than matching a zero-initialised
cache before riscv_srmcfg_init() runs.
- __switch_to_srmcfg() evaluates RCID and MCID against
cpu_srmcfg_default independently. A task in the default RCID group
with a specific MCID previously bypassed the CPU default.
- Register a CPU PM notifier that invalidates cpu_srmcfg on
CPU_PM_EXIT / CPU_PM_ENTER_FAILED so resume-from-suspend on the boot
CPU writes the CSR.
- Drop the for_each_online_cpu pre-seed loop in riscv_srmcfg_init().
cpuhp_setup_state() already covers already-online CPUs.
CBQRI:
- Add mweight_cache. cbqri_apply_bc_field() seeds both fields of
bc_bw_alloc from the software caches, so that stale data can not leak
into the unmodified field.
- Seed mweight_cache to FIELD_MAX(MWEIGHT_MASK) at probe so the first
MB_MIN domain init does not commit Mweight=0 to every RCID. A weight
of 0 is a hard cap on opportunistic bandwidth, which would starve
every RCID until the subsequent MB_WGHT domain init catches up.
- cbqri_apply_mweight_config() rejects mweight > WEIGHT_MASK at entry
rather than letting it truncate and trigger a verify mismatch.
- cbqri_apply_bc_field() updates per-RCID cache only after verifying.
- cbqri_controller_destroy() now iounmaps and releases the mem region
from rollback paths, gated on ctrl->base.
- cbqri_probe_feature() clears OP, AT, RCID and EVT_ID on every write,
so the probe never writes stale bits into the register.
- cbqri_apply_cache_config() clears cc_block_mask before the initial
READ_LIMIT that captures saved_cbm.
- Drop the ctrl->faulted early return from controller ops.
- Reject a second bandwidth controller when sharing a proximity domain.
- Rejects ctrl->rcid_count > SRMCFG_RCID_MASK so the schedule-in
fast path cannot silently truncate the RCID.
- Widen CBQRI_MON_CTL_OP/MCID/EVT_ID masks to GENMASK_ULL so
FIELD_MODIFY on a u64 register stays safe if RV32 support is added.
resctrl:
- Switch the L3 mon_domain teardown paths from cancel_delayed_work_sync
to cancel_delayed_work to avoid potential deadlock.
- Guard the mbm_over cancel on QOS_L3_MBM_TOTAL_EVENT_ID, so a system
without a paired BC does not cancel a zeroed work struct.
- cbqri_attach_cpu_to_cap_ctrl() rolls back cpumask_set_cpu and any
freshly created ctrl_domain when cbqri_attach_cpu_to_l3_mon() fails.
- Restrict mbm_total_bytes to platforms with exactly one L3 domain.
- Pair the L3 mon domain with its BC and initialise the BC's
per-MCID accumulators before resctrl_online_mon_domain() exposes
the domain, so a concurrent mbm_total_bytes read cannot race with
paired_bc init.
- Hold cbqri_domain_list_lock across the MMIO paths in
resctrl_arch_rmid_read() and resctrl_arch_reset_rmid() so a
concurrent CPU hotplug detach cannot free hw_dom mid-read.
- cbqri_resctrl_setup() rolls back exposed_alloc_capable /
exposed_mon_capable on resctrl_init() failure so
resctrl_arch_*_capable() does not report stale state to callers.
- Drop the cacheinfo_ready wait queue in cbqri_resctrl_setup() and
the RCU annotations on the ctrl_domain list. cacheinfo runs at
device_initcall_sync, strictly before late_initcall, and the list
is mutated only from cpuhp callbacks under cbqri_domain_list_lock.
Kconfig:
- RISCV_ISA_SSQOSID selects RISCV_CBQRI_DRIVER unconditionally. resctrl
is gated separately by the silent RISCV_CBQRI_RESCTRL_FS option.
ACPI:
- acpi_parse_rqsc() rejects tables with the wrong header.revision,
validates res0->type and res0->id_type, and checks that node->length
does not overrun the table end.
Sashiko review:
https://sashiko.dev/#/patchset/20260510-ssqosid-cbqri-rqsc-v7-0-v4-0-eb53831ef683%40kernel.org
Link to v4:
https://lore.kernel.org/all/20260510-ssqosid-cbqri-rqsc-v7-0-v4-0-eb53831ef683@kernel.org/
Changes in v4:
--------------
resctrl:
- Add RDT_RESOURCE_MB_MIN and RDT_RESOURCE_MB_WGHT
- Add default_to_min to resctrl_membw so MB_MIN defaults to min_bw
- Add L3 cache occupancy monitoring for L3-scoped capacity controllers
- Add mbm_total_bytes bandwidth monitoring when there is a single
bandwidth controller
- Move domain creation into cpuhp callbacks so that cpu_mask reflects
only online CPUs
- resctrl_arch_reset_rmid() returns early when called with IRQs
disabled.
CBQRI:
- Replace per-controller spinlock with mutex. Each CBQRI op is a
write-then-poll-busy cycle of up to 1 ms. A sleeping mutex paired
with readq_poll_timeout() keeps preemption enabled across the
busy-wait. All resctrl-arch entry points run in process context.
- Replace struct cbqri_config with direct params in helper functions.
- max_rmid = min(max_rmid, ctrl->mcid_count) now gated on
ctrl->mon_capable.
- Validate that the sum of Rbwb does not exceed MRBWB.
- Move CDP enable state from file-scope globals to per-resource
cdp_enabled / cdp_capable.
- Configure both AT_CODE and AT_DATA limits when CDP is supported but
not enabled.
Ssqosid:
- __switch_to_srmcfg() emits RISCV_FENCE(rw, o) before and (o, rw)
after csrw to drain old-task stores and order new-task loads.
- Invalidate per-cpu cpu_srmcfg on hart online via CPUHP_AP_ONLINE_DYN.
Also seed already-online CPUs synchronously at init.
ACPI:
- Drop the PPTT helper patch and resolve cache_size via cacheinfo at
cbqri_resctrl_setup() time.
- ACPI driver now calls riscv_cbqri_register_controller() and the
cbqri_controller internals stay in cbqri_internal.h.
Refer to v3 for previous change logs:
https://lore.kernel.org/r/20260414-ssqosid-cbqri-rqsc-v7-0-v3-0-b3b2e7e9847a@kernel.org
---
Drew Fustini (18):
dt-bindings: riscv: Add Ssqosid extension description
riscv: detect the Ssqosid extension
riscv: add support for srmcfg CSR from Ssqosid extension
fs/resctrl: Add resctrl_is_membw() helper
fs/resctrl: Add RDT_RESOURCE_MB_MIN and RDT_RESOURCE_MB_WGHT
fs/resctrl: Let bandwidth resources default to min_bw at reset
riscv_cbqri: Add capacity controller probe and allocation device ops
riscv_cbqri: Add capacity controller monitoring device ops
riscv_cbqri: Add bandwidth controller probe and allocation device ops
riscv_cbqri: Add bandwidth controller monitoring device ops
riscv_cbqri: resctrl: Add cache allocation via capacity block mask
riscv_cbqri: resctrl: Add L3 cache occupancy monitoring
riscv_cbqri: resctrl: Add MB_MIN bandwidth allocation via Rbwb
riscv_cbqri: resctrl: Add MB_WGHT bandwidth allocation via Mweight
riscv_cbqri: resctrl: Add mbm_total_bytes bandwidth monitoring
ACPI: RISC-V: Parse RISC-V Quality of Service Controller (RQSC) table
ACPI: RISC-V: Add support for RISC-V Quality of Service Controller (RQSC)
riscv: enable resctrl filesystem for Ssqosid
.../devicetree/bindings/riscv/extensions.yaml | 6 +
MAINTAINERS | 15 +
arch/riscv/Kconfig | 20 +
arch/riscv/include/asm/acpi.h | 10 +
arch/riscv/include/asm/csr.h | 5 +
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/include/asm/processor.h | 3 +
arch/riscv/include/asm/qos.h | 87 ++
arch/riscv/include/asm/resctrl.h | 152 ++
arch/riscv/include/asm/switch_to.h | 3 +
arch/riscv/kernel/Makefile | 2 +
arch/riscv/kernel/cpufeature.c | 1 +
arch/riscv/kernel/qos.c | 98 ++
drivers/acpi/riscv/Makefile | 1 +
drivers/acpi/riscv/init.c | 21 +
drivers/acpi/riscv/rqsc.c | 202 +++
drivers/acpi/riscv/rqsc.h | 66 +
drivers/resctrl/Kconfig | 32 +
drivers/resctrl/Makefile | 6 +
drivers/resctrl/cbqri_devices.c | 1154 +++++++++++++++
drivers/resctrl/cbqri_internal.h | 247 ++++
drivers/resctrl/cbqri_resctrl.c | 1520 ++++++++++++++++++++
fs/resctrl/ctrlmondata.c | 3 +-
fs/resctrl/internal.h | 2 +
fs/resctrl/rdtgroup.c | 16 +-
include/linux/resctrl.h | 13 +-
include/linux/riscv_cbqri.h | 60 +
27 files changed, 3737 insertions(+), 9 deletions(-)
---
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
change-id: 20260329-ssqosid-cbqri-rqsc-v7-0-b0c788bab48a
Best regards,
--
Drew Fustini <fustini@kernel.org>
^ permalink raw reply
* Re: [PATCH] Documentation: Fix syntax of kmalloc_objs example in coding style doc
From: Kees Cook @ 2026-06-01 20:08 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jonathan Corbet, Manuel Ebner, Vlastimil Babka (SUSE),
SeongJae Park, Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <20260529081006.2019687-2-ukleinek@kernel.org>
On Fri, May 29, 2026 at 10:10:05AM +0200, Uwe Kleine-König wrote:
> The first parameter should match the variable that the allocated memory
> is assigned to. Fix the example accordingly, the one for kmalloc_obj got
> it right already.
>
> Fixes: 7c6d969d5349 ("Documentation: adopt new coding style of type-aware kmalloc-family")
> Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
oops, thank you!
Reviewed-by: Kees Cook <kees@kernel.org>
--
Kees Cook
^ permalink raw reply
* Re: [RFC PATCH v1 00/13] exec: add spawn templates for repeated executable startup
From: Kees Cook @ 2026-06-01 19:55 UTC (permalink / raw)
To: Christian Brauner
Cc: Li Chen, Alexander Viro, linux-fsdevel, linux-api, linux-kernel,
linux-mm, linux-arch, linux-doc, linux-kselftest, x86,
Arnd Bergmann, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Jan Kara,
Jonathan Corbet, Shuah Khan
In-Reply-To: <20260528-madig-fachrichtung-fehlinformation-61117ba640da@brauner>
On Thu, May 28, 2026 at 01:02:53PM +0200, Christian Brauner wrote:
> On Thu, May 28, 2026 at 05:52:21PM +0800, Li Chen wrote:
> > Hi,
> >
> > This is an early RFC for an idea that is probably still rough in both the
> > UAPI and implementation details. Sorry for the rough edges; I am sending
> > it now to check whether this direction is worth pursuing and to get
> > feedback on the kernel/userspace boundary.
>
> The idea of having a builder api for exec isn't all that crazy. But it
> should simply be built on top of pidfds and thus pidfs itself instead.
> It has all the basic infrastructure in place already. Any implementation
> should also allow userspace to implement posix_spawn() on top of it.
>
> fd = pidfd_open(0, PIDFD_EMPTY /* or better name */)
>
> pidfd_config(fd, ...) // modeled similar to fsconfig()
FWIW, I agree this should be modelled after fsconfig and built on pidfs.
Doing so will avoid a bunch of design issues, etc.
-Kees
--
Kees Cook
^ permalink raw reply
* [PATCH] docs: pt_BR: Translate 3.Early-stage.rst into Portuguese
From: Daniel Pereira @ 2026-06-01 19:23 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Daniel Pereira
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 14288 bytes --]
Translate the documentation file '3.Early-stage.rst' into Portuguese.
This section addresses corporate kernel development constraints,
the balance between company secrecy and the open-loop approach,
and the use of NDAs or Linux Foundation programs to avoid
integration issues.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
.../pt_BR/process/3.Early-stage.rst | 233 ++++++++++++++++++
.../pt_BR/process/development-process.rst | 1 +
2 files changed, 234 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/3.Early-stage.rst
diff --git a/Documentation/translations/pt_BR/process/3.Early-stage.rst b/Documentation/translations/pt_BR/process/3.Early-stage.rst
new file mode 100644
index 000000000..74e741766
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/3.Early-stage.rst
@@ -0,0 +1,233 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Planejamento em estágio inicial
+===============================
+
+Ao contemplar um projeto de desenvolvimento do kernel Linux, pode ser tentador
+dar um salto direto e começar a codificar. No entanto, como ocorre com qualquer
+projeto significativo, grande parte da base para o sucesso é melhor estabelecida
+antes que a primeira linha de código seja escrita. Um tempo gasto no planejamento
+e na comunicação iniciais pode economizar muito mais tempo mais adiante.
+
+
+Especificando o problema
+------------------------
+
+Como qualquer projeto de engenharia, um aprimoramento bem-sucedido do kernel
+começa com uma descrição clara do problema a ser resolvido. Em alguns casos,
+esta etapa é fácil: quando um driver é necessário para um componente de
+hardware específico, por exemplo. Em outros, no entanto, é tentador confundir o
+problema real com a solução proposta, e isso pode levar a dificuldades.
+
+Considere um exemplo: alguns anos atrás, desenvolvedores que trabalhavam com o
+áudio do Linux buscavam uma maneira de executar aplicativos sem interrupções
+(*dropouts*) ou outros artefatos causados por latência excessiva no sistema. A
+solução a que chegaram foi um módulo do kernel destinado a se conectar à
+estrutura do Linux Security Module (LSM); esse módulo poderia ser configurado
+para dar a aplicativos específicos acesso ao escalonador de tempo real. Esse
+módulo foi implementado e enviado para a lista de discussão linux-kernel, onde
+imediatamente encontrou problemas.
+
+Para os desenvolvedores de áudio, esse módulo de segurança era suficiente para
+resolver o problema imediato deles. Para a comunidade mais ampla do kernel, no
+entanto, ele foi visto como um uso indevido da estrutura LSM (que não tem a
+intenção de conceder privilégios a processos que eles de outra forma não
+teriam) e um risco para a estabilidade do sistema. As soluções preferidas da
+comunidade envolviam o acesso ao escalonamento de tempo real via mecanismo
+rlimit a curto prazo, e o trabalho contínuo de redução de latência a longo prazo.
+
+A comunidade de áudio, no entanto, não conseguia enxergar além da solução
+específica que havia implementado; eles não estavam dispostos a aceitar
+alternativas. O desacordo resultante deixou esses desenvolvedores sentindo-se
+desiludidos com todo o processo de desenvolvimento do kernel; um deles voltou
+para uma lista de áudio e postou isto:
+
+ "Existe um bom número de desenvolvedores muito bons no kernel Linux, mas eles
+ tendem a ser abafados por uma grande multidão de tolos arrogantes. Tentar
+ comunicar os requisitos dos usuários a essas pessoas é uma perda de tempo.
+ Eles são 'inteligentes' demais para ouvir os meros mortais."
+
+(https://lwn.net/Articles/131776/).
+
+A realidade da situação era diferente; os desenvolvedores do kernel estavam muito
+mais preocupados com a estabilidade do sistema, com a manutenção a longo prazo e
+em encontrar a solução correta para o problema do que com um módulo específico.
+A moral da história é focar no problema — e não em uma solução específica — e
+discuti-lo com a comunidade de desenvolvimento antes de investir na criação de
+um conjunto de códigos.
+
+Portanto, ao contemplar um projeto de desenvolvimento do kernel, deve-se
+obter respostas para um pequeno conjunto de perguntas:
+
+ - Qual é, exatamente, o problema que precisa ser resolvido?
+
+ - Quem são os usuários afetados por esse problema? Quais casos de uso a
+ solução deve abranger?
+
+ - De que forma o kernel deixa a desejar em resolver esse problema atualmente?
+
+Só então faz sentido começar a considerar possíveis soluções.
+
+
+Discussão inicial
+-----------------
+
+Ao planejar um projeto de desenvolvimento do kernel, faz todo o sentido realizar
+discussões com a comunidade antes de iniciar a implementação. A comunicação
+inicial pode economizar tempo e problemas de várias maneiras:number of ways:
+
+ - Pode muito bem ser que o problema já seja tratado pelo kernel de maneiras
+ que você não compreendeu. O kernel Linux é grande e possui uma série de
+ recursos e capacidades que não são imediatamente óbvios. Nem todas as
+ capacidades do kernel são documentadas tão bem quanto se gostaria, e é fácil
+ deixar passar algumas coisas. Este autor já viu a postagem de um driver
+ completo que duplicava um driver existente do qual o novo autor não tinha
+ conhecimento. Códigos que reinventam as rodas existentes não são apenas um
+ desperdício; eles também não serão aceitos no kernel principal (*mainline*).
+
+ - Pode haver elementos na solução proposta que não serão aceitáveis para a
+ integração no kernel principal . É melhor descobrir problemas
+ como este antes de escrever o código.
+
+ - É inteiramente possível que outros desenvolvedores já tenham pensado sobre
+ o problema; eles podem ter ideias para uma solução melhor e podem estar
+ dispostos a ajudar na criação dessa solução.
+
+Anos de experiência com a comunidade de desenvolvimento do kernel ensinaram uma
+lição clara: códigos do kernel que são projetados e desenvolvidos a portas
+fechadas invariavelmente apresentam problemas que só são revelados quando o
+código é lançado na comunidade. Às vezes, esses problemas são graves, exigindo
+meses ou anos de esforço antes que o código possa ser adequado aos padrões da
+comunidade do kernel. Alguns exemplos incluem:
+
+ - A pilha de rede Devicescape foi projetada e implementada para sistemas
+ monoprocessados. Ela não pôde ser integrada ao kernel principal (*mainline*)
+ até que fosse adaptada para sistemas multiprocessados. Ajustar retroativamente
+ mecanismos de travamento (*locking*) e afins em um código é uma tarefa difícil;
+ como resultado, a integração desse código (hoje chamado mac80211) foi atrasada
+ por mais de um ano.
+
+ - O sistema de arquivos Reiser4 incluía uma série de capacidades que, na
+ opinião dos desenvolvedores principais do kernel, deveriam ter sido
+ implementadas na camada de sistema de arquivos virtual (*Virtual Filesystem*
+ ou VFS). Ele também incluía recursos que não podiam ser facilmente
+ implementados sem expor o sistema a travamentos mútuos (*deadlocks*) causados
+ pelo usuário. A revelação tardia desses problemas — e a recusa em corrigir
+ alguns deles — fez com que o Reiser4 permanecesse fora do kernel principal
+ (*mainline*).
+
+ - O módulo de segurança AppArmor fazia uso de estruturas de dados internas
+ do sistema de arquivos virtual de maneiras que eram
+ consideradas inseguras e não confiáveis. Essa preocupação (entre outras)
+ manteve o AppArmor fora do kernel principal (*mainline*) por anos.
+
+In each of these cases, a great deal of pain and extra work could have been
+avoided with some early discussion with the kernel developers.
+
+
+Como encontrar os mantenedores?
+-------------------------------
+
+Quando os desenvolvedores decidem tornar seus planos públicos, a próxima
+pergunta será: por onde começamos? A resposta é encontrar a(s) lista(s) de
+discussão correta(s) e o mantenedor adequado. Para listas de discussão, a
+melhor abordagem é procurar no arquivo MAINTAINERS por um local relevante para
+postar. Se houver uma lista de subsistema adequada, postar nela costuma ser
+preferível a postar na linux-kernel; é mais provável que você alcance
+desenvolvedores com experiência no subsistema relevante e o ambiente pode ser
+mais acolhedor.
+
+Encontrar os mantenedores pode ser um pouco mais difícil. Novamente, o arquivo
+MAINTAINERS é o lugar para começar. No entanto, esse arquivo tende a não estar
+sempre atualizado, e nem todos os subsistemas estão representados ali. A
+pessoa listada no arquivo MAINTAINERS pode, na verdade, não ser quem está
+atuando nessa função atualmente. Portanto, quando houver dúvidas sobre quem
+contactar, um truque útil é usar o git (e o "git log" em particular) para ver
+quem está ativo no momento dentro do subsistema de interesse. Observe quem
+está escrevendo os patches e quem, se houver alguém, está anexando linhas
+"Signed-off-by" a esses patches. Essas são as pessoas que estarão em melhor
+posição para ajudar com um novo projeto de desenvolvimento.
+
+A tarefa de encontrar o mantenedor correto às vezes é desafiadora o suficiente
+para que os desenvolvedores do kernel tenham adicionado um script para facilitar
+o processo:
+
+::
+
+ .../scripts/get_maintainer.pl
+
+Este script retornará o(s) mantenedor(es) atual(is) para um determinado arquivo
+ou diretório quando fornecida a opção "-f". Se receber um patch na linha de
+comando, ele listará os mantenedores que provavelmente devem receber cópias do
+patch. Esta é a maneira preferencial (ao contrário da opção "-f") de obter a
+lista de pessoas para incluir em cópia (Cc) nos seus patches. Há uma série de
+opções que regulam o quão profundamente o get_maintainer.pl buscará por
+mantenedores; por favor, tenha cuidado ao usar as opções mais agressivas, pois
+você pode acabar incluindo desenvolvedores que não têm interesse real no código
+que você está modificando.
+
+Se tudo mais falhar, falar com Andrew Morton pode ser uma maneira eficaz de
+rastrear um mantenedor para um trecho específico de código.
+
+
+Quando postar?
+--------------
+
+Se possível, postar seus planos durante os estágios iniciais só pode
+ser útil. Descreva o problema que está sendo resolvido e quaisquer
+planos que tenham sido feitos sobre como a implementação será feita.
+Qualquer informação que você possa fornecer pode ajudar a comunidade de
+desenvolvimento a dar contribuições úteis sobre o projeto.
+
+Uma coisa desanimadora que pode acontecer neste estágio não é uma
+reação hostil, mas, em vez disso, pouca ou nenhuma reação. A triste
+verdade sobre o assunto é que (1) os desenvolvedores do kernel tendem a
+estar ocupados, (2) não há escassez de pessoas com planos grandiosos e
+pouco código (ou mesmo perspectiva de código) para apoiá-los, e (3)
+ninguém é obrigado a revisar ou comentar sobre ideias postadas por
+outros. Além disso, designs de alto nível frequentemente escondem
+problemas que só são revelados quando alguém realmente tenta
+implementar esses designs; por essa razão, os desenvolvedores do kernel
+preferem ver o código.
+
+Se uma postagem de pedido de comentários (RFC) render poucos
+comentários, não presuma que isso significa que não há interesse no
+projeto. Infelizmente, você também não pode presumir que não há
+problemas com sua ideia. A melhor coisa a fazer nesta situação é
+prosseguir, mantendo a comunidade informada à medida que avança.
+
+
+Obter a aprovação oficial
+-------------------------
+
+Se o seu trabalho estiver sendo realizado em um ambiente corporativo como é o
+caso da maior parte do trabalho no kernel do Linux —, você deve, obviamente, ter
+a permissão de gerentes devidamente autorizados antes de poder publicar os
+planos ou o código da sua empresa em uma lista de discussão pública.
+A publicação de código que não tenha sido liberado para lançamento sob uma
+licença compatível com a GPL pode ser especialmente problemática; quanto mais
+cedo a gerência e a equipe jurídica de uma empresa puderem entrar em acordo
+sobre a publicação de um projeto de desenvolvimento do kernel, melhor será para
+todos os envolvidos.
+
+Alguns leitores podem estar pensando, neste ponto, que o seu trabalho no kernel
+se destina a dar suporte a um produto que ainda não tem uma existência oficialmente
+reconhecida. Revelar os planos de seu empregador em uma lista de discussão pública
+pode não ser uma opção viável. Em casos como esse, vale a pena considerar se o
+segredo é realmente necessário; muitas vezes não há uma real necessidade de manter
+os planos de desenvolvimento a portas fechadas.
+
+Dito isso, também existem casos em que uma empresa legitimamente não pode
+revelar seus planos logo no início do processo de desenvolvimento. Empresas com
+desenvolvedores de kernel experientes podem optar por prosseguir de maneira isolada
+(em "malha aberta"), partindo do pressuposto de que serão capazes de evitar problemas
+graves de integração mais tarde. Para empresas que não possuem esse tipo de expertise
+interna, a melhor opção costuma ser a contratação de um desenvolvedor externo para
+revisar os planos sob um acordo de confidencialidade (NDA). A Linux Foundation opera
+um programa de NDA projetado para ajudar nesse tipo de situação; mais informações
+podem ser encontradas em:
+
+ https://www.linuxfoundation.org/nda/
+
+Esse tipo de revisão costuma ser suficiente para evitar problemas graves mais
+tarde, sem a necessidade de uma divulgação pública do projeto.
diff --git a/Documentation/translations/pt_BR/process/development-process.rst b/Documentation/translations/pt_BR/process/development-process.rst
index 737fdcdff..599c34c85 100644
--- a/Documentation/translations/pt_BR/process/development-process.rst
+++ b/Documentation/translations/pt_BR/process/development-process.rst
@@ -19,3 +19,4 @@ conhecimento profundo de programação de kernel para ser compreendida.
1.Intro
2.Process
+ 3.Early-stage
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 0/2] 2 dydnbg doc fixes
From: Jonathan Corbet @ 2026-06-01 19:12 UTC (permalink / raw)
To: Jim Cromie, Shuah Khan; +Cc: linux-doc, linux-kernel, Jim Cromie, Louis Chauvet
In-Reply-To: <20260502-dyndbg-doc-v1-0-67cc4a93a77e@gmail.com>
Jim Cromie <jim.cromie@gmail.com> writes:
> 1st swaps \012 for \n to match actual output in dynamic_debug/control
>
> 2nd explains that flags input to >dynamic_debug/control is checked
> before keyword value pairs, which might not be there.
>
> Both reflect current code behavior.
>
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> ---
> Jim Cromie (2):
> docs/dyndbg: update examples \012 to \n
> docs/dyndbg: explain flags parse 1st
>
> Documentation/admin-guide/dynamic-debug-howto.rst | 35 ++++++++++++++---------
> 1 file changed, 22 insertions(+), 13 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v5] PM: QoS: Introduce boot parameter pm_qos_resume_latency_us
From: Rafael J. Wysocki @ 2026-06-01 19:08 UTC (permalink / raw)
To: Aaron Tomlin
Cc: gregkh, rafael, dakr, pavel, lenb, zhongqiu.han, akpm, bp,
pmladek, rdunlap, feng.tang, pawan.kumar.gupta, kees, elver, arnd,
fvdl, lirongqing, bhelgaas, neelx, sean, mproche, chjohnst,
nick.lange, linux-kernel, linux-pm, linux-doc
In-Reply-To: <76opmfrrzgjgd2m7pnzjdd5h4a3bc3ofz4xwsxuavulnqslsm7@fuirka5jro5j>
On Mon, Jun 1, 2026 at 8:55 PM Aaron Tomlin <atomlin@atomlin.com> wrote:
>
> On Sun, Apr 26, 2026 at 12:01:27PM -0400, Aaron Tomlin wrote:
> > This patch introduces the pm_qos_resume_latency_us kernel boot
> > parameter, which allows users to specify distinct resume latency
> > constraints for specific CPU ranges.
> >
> > Syntax: pm_qos_resume_latency_us=range:value;range:value...
> >
> > This boot parameter mirrors the sysfs interface behaviour: the special
> > string "n/a" imposes a 0us latency constraint (polling), while the
> > integer 0 removes the constraint entirely.
>
> Hi Greg, Rafael, Danilo, Pavel, Len,
>
> It has been over a month since I submitted this, so I just wanted to gently
> ping this thread.
>
> As a quick reminder, this parameter is highly beneficial for deployments
> that prefer to establish strict latency constraints early in the boot
> process, eliminating the need to rely on custom user-space tooling later
> on.
>
> Patch link: https://lore.kernel.org/lkml/20260426160127.292486-1-atomlin@atomlin.com/
>
> Please let me know if you have any conceptual concerns with this approach,
> if any further adjustments are required,
IMV it would be better to call the new command line arg something like
"cpu_idle_exit_latency_us" to make it clear what it is about.
Also, generally speaking, it should be part of cpuidle rather than the
generic QoS code that also applies to devices other than CPUs.
> or if you simply need me to rebase and resend this against the latest power management tree.
And that too.
Thanks!
^ permalink raw reply
* Re: [PATCH v1] docs: kernel-parameters: Fix stale sticore file paths
From: Jonathan Corbet @ 2026-06-01 19:08 UTC (permalink / raw)
To: Costa Shulyupin, Shuah Khan, Randy Dunlap, linux-doc,
linux-kernel
Cc: Costa Shulyupin
In-Reply-To: <20260531140541.4115641-1-costa.shul@redhat.com>
Costa Shulyupin <costa.shul@redhat.com> writes:
> Update file paths for sticore references that
> became stale when drivers were reorganized:
> - drivers/video/console/sticore.c -> drivers/video/
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 459ed0d72aeb..f94ec9f3a75c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -7381,10 +7381,10 @@ Kernel parameters
> Set the STI (builtin display/keyboard on the HP-PARISC
> machines) console (graphic card) which should be used
> as the initial boot-console.
> - See also comment in drivers/video/console/sticore.c.
> + See also comment in drivers/video/sticore.c.
>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v1] docs: real-time: Fix duplicated sched(7) text
From: Jonathan Corbet @ 2026-06-01 19:06 UTC (permalink / raw)
To: Costa Shulyupin, Sebastian Andrzej Siewior, Clark Williams,
Steven Rostedt, Shuah Khan, Randy Dunlap, linux-rt-devel,
linux-doc, linux-kernel
Cc: Costa Shulyupin
In-Reply-To: <20260531141823.4118954-1-costa.shul@redhat.com>
Costa Shulyupin <costa.shul@redhat.com> writes:
> The man page reference appeared twice - once as plain text and
> once as a hyperlink. Remove the plain text duplicate.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/core-api/real-time/theory.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/core-api/real-time/theory.rst b/Documentation/core-api/real-time/theory.rst
> index 43d0120737f8..92de5654163d 100644
> --- a/Documentation/core-api/real-time/theory.rst
> +++ b/Documentation/core-api/real-time/theory.rst
> @@ -25,7 +25,7 @@ Scheduling
> ==========
>
> The core principles of Linux scheduling and the associated user-space API are
> -documented in the man page sched(7)
> +documented in the man page
> `sched(7) <https://man7.org/linux/man-pages/man7/sched.7.html>`_.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v1] docs: kgdb: Fix stale source file paths
From: Jonathan Corbet @ 2026-06-01 19:04 UTC (permalink / raw)
To: Costa Shulyupin, Jason Wessel, Daniel Thompson, Douglas Anderson,
Shuah Khan, Randy Dunlap, kgdb-bugreport, workflows, linux-doc,
linux-kernel
Cc: Costa Shulyupin
In-Reply-To: <20260531140207.4114764-1-costa.shul@redhat.com>
Costa Shulyupin <costa.shul@redhat.com> writes:
> Update two file paths that became stale when kgdb/kdb sources
> were reorganized:
> - kernel/debugger/debug_core.c -> kernel/debug/debug_core.c
> - drivers/char/kdb_keyboard.c -> kernel/debug/kdb/kdb_keyboard.c
...which happened for 2.6.35 in 2009...
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/process/debugging/kgdb.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v1] docs: sonypi: Fix stale header file path
From: Jonathan Corbet @ 2026-06-01 19:03 UTC (permalink / raw)
To: Costa Shulyupin, Shuah Khan, Randy Dunlap, linux-doc,
linux-kernel
Cc: Costa Shulyupin
In-Reply-To: <20260531135850.4113774-1-costa.shul@redhat.com>
Costa Shulyupin <costa.shul@redhat.com> writes:
> The sonypi.h header was moved from drivers/char/ to
> include/linux/. Update the reference.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/admin-guide/laptops/sonypi.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/laptops/sonypi.rst b/Documentation/admin-guide/laptops/sonypi.rst
> index 7541f56e0007..fb8f4a30ddce 100644
> --- a/Documentation/admin-guide/laptops/sonypi.rst
> +++ b/Documentation/admin-guide/laptops/sonypi.rst
> @@ -89,7 +89,7 @@ statically linked into the kernel). Those options are:
> set to 0xffffffff, meaning that all possible events
> will be tried. You can use the following bits to
> construct your own event mask (from
> - drivers/char/sonypi.h)::
> + include/linux/sonypi.h)::
>
I suspect this driver has not been used in a long time, but as long as
it's around the documentation should at least not be obviously wrong.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v1] docs: kernel-parameters: Remove sa1100ir IrDA parameter
From: Jonathan Corbet @ 2026-06-01 18:59 UTC (permalink / raw)
To: Costa Shulyupin, Shuah Khan, Randy Dunlap, linux-doc,
linux-kernel
Cc: Costa Shulyupin
In-Reply-To: <20260531135455.4113157-1-costa.shul@redhat.com>
Costa Shulyupin <costa.shul@redhat.com> writes:
> The sa1100ir parameter referenced drivers/net/irda/sa1100_ir.c,
> which was removed along with the entire IrDA stack in commit d64c2a76123f
> ("staging: irda: remove the irda network stack and drivers").
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 4420eb72b378..459ed0d72aeb 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -6735,8 +6735,6 @@ Kernel parameters
> restrictions other than those given by hardware at the
> cost of significant additional memory use for tables.
>
> - sa1100ir [NET]
> - See drivers/net/irda/sa1100_ir.c.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] iommu: Documentation: rearrange, update kernel-parameters
From: Jonathan Corbet @ 2026-06-01 18:58 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Randy Dunlap, Shuah Khan, linux-doc, Joerg Roedel, Will Deacon,
Robin Murphy, iommu, Borislav Petkov
In-Reply-To: <20260528054611.1524937-1-rdunlap@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> Add text for some undescribed iommu= parameters (merge, nomerge,
> biomerge, panic, nopanic, pt, nopt). Add "usedac" and its description.
> Add that iommu=pt is equivalent to iommu.passthrough=1
> and that iommu=nopt is equivalent to iommu.passthrough=0.
>
> Move the PPC/POWERNV heading & its option "nobypass" to a separate
> area since the current "iommu=" applies only to X86 (according to
> its heading).
>
> Unindent the AMD GART IOMMU options heading to make it stand out.
> Also add its kconfig symbol name to be explicit about what these
> options apply to.
>
> Make sure that the IOMMU options that are listed under AMD Gart
> HW IOMMU-specific options are only for that product; i.e., add "force"
> there and move "merge", "nomerge", and "panic" to the general IOMMU
> options area.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v5] PM: QoS: Introduce boot parameter pm_qos_resume_latency_us
From: Aaron Tomlin @ 2026-06-01 18:55 UTC (permalink / raw)
To: gregkh, rafael, dakr, pavel, lenb
Cc: zhongqiu.han, akpm, bp, pmladek, rdunlap, feng.tang,
pawan.kumar.gupta, kees, elver, arnd, fvdl, lirongqing, bhelgaas,
neelx, sean, mproche, chjohnst, nick.lange, linux-kernel,
linux-pm, linux-doc
In-Reply-To: <20260426160127.292486-1-atomlin@atomlin.com>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On Sun, Apr 26, 2026 at 12:01:27PM -0400, Aaron Tomlin wrote:
> This patch introduces the pm_qos_resume_latency_us kernel boot
> parameter, which allows users to specify distinct resume latency
> constraints for specific CPU ranges.
>
> Syntax: pm_qos_resume_latency_us=range:value;range:value...
>
> This boot parameter mirrors the sysfs interface behaviour: the special
> string "n/a" imposes a 0us latency constraint (polling), while the
> integer 0 removes the constraint entirely.
Hi Greg, Rafael, Danilo, Pavel, Len,
It has been over a month since I submitted this, so I just wanted to gently
ping this thread.
As a quick reminder, this parameter is highly beneficial for deployments
that prefer to establish strict latency constraints early in the boot
process, eliminating the need to rely on custom user-space tooling later
on.
Patch link: https://lore.kernel.org/lkml/20260426160127.292486-1-atomlin@atomlin.com/
Please let me know if you have any conceptual concerns with this approach,
if any further adjustments are required, or if you simply need me to rebase
and resend this against the latest power management tree.
Thank you for your time.
Kind regards
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] docs: md: fix grammar in speed_limit description
From: Jonathan Corbet @ 2026-06-01 18:51 UTC (permalink / raw)
To: Miguel Martín Gil
Cc: skhan, linux-doc, linux-kernel, Miguel Martín Gil
In-Reply-To: <20260525214554.2196-1-miguel.martin.gil.uni@gmail.com>
Miguel Martín Gil <miguel.martin.gil.uni@gmail.com> writes:
> Replace 'This are' with 'These are' in the md sysfs speed limit
> section to correct grammar and improve readability.
>
> Signed-off-by: Miguel Martín Gil <miguel.martin.gil.uni@gmail.com>
> ---
> Documentation/admin-guide/md.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst
> index dc7eab191..003fd34f7 100644
> --- a/Documentation/admin-guide/md.rst
> +++ b/Documentation/admin-guide/md.rst
> @@ -734,7 +734,7 @@ also have
> They should be scaled by the bitmap_chunksize.
>
> sync_speed_min, sync_speed_max
> - This are similar to ``/proc/sys/dev/raid/speed_limit_{min,max}``
> + These are similar to ``/proc/sys/dev/raid/speed_limit_{min,max}``
> however they only apply to the particular array.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: changes.rst: restore pahole 1.26 minimum (regressed by sort)
From: Jonathan Corbet @ 2026-06-01 18:50 UTC (permalink / raw)
To: Zhan Xusheng; +Cc: Shuah Khan, workflows, linux-doc, linux-kernel, Zhan Xusheng
In-Reply-To: <20260526022033.1301884-1-zhanxusheng@xiaomi.com>
Zhan Xusheng <zhanxusheng1024@gmail.com> writes:
> Commit 9edd04c4189e ("docs: Raise minimum pahole version to 1.26 for
> KF_IMPLICIT_ARGS kfuncs") raised the minimum required pahole version
> from 1.22 to 1.26 in the requirements table and added a paragraph
> explaining the failure mode for distributions still shipping pahole
> v1.25 (e.g. Ubuntu 24.04 LTS).
>
> The next day, commit ece7e57afd51 ("docs: changes.rst and ver_linux:
> sort the lists") came through a different tree (docs vs sched_ext) and
> re-flowed the table alphabetically, but its base did not include
> 9edd04c4189e. When the two commits met in mainline, the textual rewrite
> of the table won and the version bump was lost. The added "Since Linux
> 7.0..." paragraph also disappeared.
>
> The result is that changes.rst on master (v7.1-rc5) lists pahole 1.22
> again, even though sched_ext kfuncs annotated with KF_IMPLICIT_ARGS
> genuinely require v1.26 to produce a correct vmlinux BTF. Users on
> distributions with pahole v1.25 hit "func_proto incompatible with
> vmlinux" when loading any sched_ext BPF program (scx_simple,
> scx_qmap, ...) and have no documentation pointing them at the version
> gap.
>
> Restore both changes from 9edd04c4189e.
>
> Fixes: ece7e57afd51 ("docs: changes.rst and ver_linux: sort the lists")
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> ---
> Documentation/process/changes.rst | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Oops, that is not good. Thanks for catching that; fix applied.
jon
^ permalink raw reply
* Re: [PATCH] Documentation: Fix syntax of kmalloc_objs example in coding style doc
From: Jonathan Corbet @ 2026-06-01 18:48 UTC (permalink / raw)
To: Uwe Kleine-König, Manuel Ebner, Vlastimil Babka (SUSE),
SeongJae Park
Cc: Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <20260529081006.2019687-2-ukleinek@kernel.org>
Uwe Kleine-König <ukleinek@kernel.org> writes:
> The first parameter should match the variable that the allocated memory
> is assigned to. Fix the example accordingly, the one for kmalloc_obj got
> it right already.
>
> Fixes: 7c6d969d5349 ("Documentation: adopt new coding style of type-aware kmalloc-family")
> Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
> ---
> Documentation/process/coding-style.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index a3bf75dc7c88..a8336582f60b 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -959,13 +959,13 @@ The preferred form for allocating an array is the following:
>
> .. code-block:: c
>
> - p = kmalloc_objs(*ptr, n, ...);
> + p = kmalloc_objs(*p, n, ...);
>
> The preferred form for allocating a zeroed array is the following:
>
> .. code-block:: c
>
> - p = kzalloc_objs(*ptr, n, ...);
> + p = kzalloc_objs(*p, n, ...);
>
> Both forms check for overflow on the allocation size n * sizeof(...),
> and return NULL if that occurred.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2] docs: pt_BR: update maintainer-handbooks
From: Jonathan Corbet @ 2026-06-01 18:46 UTC (permalink / raw)
To: Amanda Corrêa, Daniel Pereira; +Cc: linux-doc, Amanda Corrêa
In-Reply-To: <20260528041958.57231-1-amandacorreasilvax@gmail.com>
Amanda Corrêa <amandacorreasilvax@gmail.com> writes:
> Update the content of the maintainer-handbooks documentation
> to Brazilian Portuguese.
>
> v2: Update maintainer-handbooks documentation based on the actual latest version of the English
> documentation. Prior version was based on an older version of the English documentation, which caused
> some inconsistencies between the two versions.
> This update ensures that the Brazilian Portuguese documentation is in sync with the latest English
> version, providing accurate and up-to-date information.
>
> Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
> ---
> .../pt_BR/process/maintainer-handbooks.rst | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
I have applied this, thanks.
For future reference:
- It is good to say what changed in a new version of the patch, but
please put that information after the "---" line so that the
maintainer does not have to edit it out.
- New versions of a patch should be posted standalone, rather than as a
response to a previous version.
Thanks for working to improve our documentation!
jn
^ permalink raw reply
* [PATCH v4 2/2] hwmon: (pmbus/max20860a) Add driver for Analog Devices MAX20860A
From: Pradhan, Sanman @ 2026-06-01 18:45 UTC (permalink / raw)
To: linux-hwmon@vger.kernel.org
Cc: linux@roeck-us.net, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, noname.nuno@gmail.com, Syed, Arif,
Sanman Pradhan
In-Reply-To: <20260601184516.919488-1-sanman.pradhan@hpe.com>
From: Syed Arif <arif.syed@hpe.com>
Add a PMBus driver for the Analog Devices MAX20860A step-down DC-DC
switching regulator. The MAX20860A provides monitoring of input/output
voltage, output current, and temperature via the PMBus interface using
linear data format. Optional regulator support is available via
CONFIG_SENSORS_MAX20860A_REGULATOR.
Signed-off-by: Syed Arif <arif.syed@hpe.com>
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
---
Changes since v3:
- Added optional regulator support via CONFIG_SENSORS_MAX20860A_REGULATOR
Changes since v2:
- Drop "maxim,max20860a" OF match entry
Changes since v1:
- Removed WRITE_PROTECT write from probe
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/max20860a.rst | 57 ++++++++++++++++++++++++++
MAINTAINERS | 8 ++++
drivers/hwmon/pmbus/Kconfig | 19 +++++++++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/max20860a.c | 68 +++++++++++++++++++++++++++++++
6 files changed, 154 insertions(+)
create mode 100644 Documentation/hwmon/max20860a.rst
create mode 100644 drivers/hwmon/pmbus/max20860a.c
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index e880c6ca84f0..ffaacda416e7 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -163,6 +163,7 @@ Hardware Monitoring Kernel Drivers
max20730
max20751
max20830
+ max20860a
max31722
max31730
max31760
diff --git a/Documentation/hwmon/max20860a.rst b/Documentation/hwmon/max20860a.rst
new file mode 100644
index 000000000000..ea6d2228fafc
--- /dev/null
+++ b/Documentation/hwmon/max20860a.rst
@@ -0,0 +1,57 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver max20860a
+=======================
+
+Supported chips:
+
+ * Analog Devices MAX20860A
+
+ Prefix: 'max20860a'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/max20860a.html
+
+Author:
+
+ - Syed Arif <arif.syed@hpe.com>
+ - Sanman Pradhan <psanman@juniper.net>
+
+
+Description
+-----------
+
+This driver supports hardware monitoring for Analog Devices MAX20860A
+Step-Down Switching Regulator with PMBus Interface.
+
+The MAX20860A is a fully integrated step-down DC-DC switching regulator.
+Through the PMBus interface, the device can monitor input/output voltages,
+output current and temperature.
+
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate
+the devices explicitly.
+
+Sysfs entries
+-------------
+
+================= ========================================
+in1_label "vin"
+in1_input Measured input voltage
+in1_alarm Input voltage alarm
+in2_label "vout1"
+in2_input Measured output voltage
+in2_alarm Output voltage alarm
+curr1_label "iout1"
+curr1_input Measured output current
+curr1_alarm Output current alarm
+temp1_input Measured temperature
+temp1_alarm Chip temperature alarm
+temp2_input Measured temperature (secondary)
+================= ========================================
diff --git a/MAINTAINERS b/MAINTAINERS
index b71acb130395..1d9651947ee3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15688,6 +15688,14 @@ F: Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
F: Documentation/hwmon/max20830.rst
F: drivers/hwmon/pmbus/max20830.c
+MAX20860A HARDWARE MONITOR DRIVER
+M: Sanman Pradhan <psanman@juniper.net>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
+F: Documentation/hwmon/max20860a.rst
+F: drivers/hwmon/pmbus/max20860a.c
+
MAX2175 SDR TUNER DRIVER
M: Ramesh Shanmugasundaram <rashanmu@gmail.com>
L: linux-media@vger.kernel.org
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 64f38654f4e7..f330dc3f21fe 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -402,6 +402,25 @@ config SENSORS_MAX20830
This driver can also be built as a module. If so, the module will
be called max20830.
+config SENSORS_MAX20860A
+ tristate "Analog Devices MAX20860A"
+ help
+ If you say yes here you get hardware monitoring support for Analog
+ Devices MAX20860A step-down converter.
+
+ This driver can also be built as a module. If so, the module will
+ be called max20860a.
+
+config SENSORS_MAX20860A_REGULATOR
+ bool "Regulator support for MAX20860A"
+ depends on SENSORS_MAX20860A && REGULATOR
+ help
+ If you say yes here you get regulator support for Analog Devices
+ MAX20860A step-down converter.
+
+ This enables the MAX20860A to be used as a regulator device,
+ providing voltage control through the regulator framework.
+
config SENSORS_MAX31785
tristate "Maxim MAX31785 and compatibles"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 1f2c73b71953..ffc05f493213 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_SENSORS_MAX17616) += max17616.o
obj-$(CONFIG_SENSORS_MAX20730) += max20730.o
obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
obj-$(CONFIG_SENSORS_MAX20830) += max20830.o
+obj-$(CONFIG_SENSORS_MAX20860A) += max20860a.o
obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
obj-$(CONFIG_SENSORS_MAX8688) += max8688.o
diff --git a/drivers/hwmon/pmbus/max20860a.c b/drivers/hwmon/pmbus/max20860a.c
new file mode 100644
index 000000000000..905f916f6c08
--- /dev/null
+++ b/drivers/hwmon/pmbus/max20860a.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hardware monitoring driver for Analog Devices MAX20860A
+ *
+ * SPDX-FileCopyrightText: Copyright Hewlett Packard Enterprise Development LP
+ */
+
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/regulator/driver.h>
+#include "pmbus.h"
+
+#if IS_ENABLED(CONFIG_SENSORS_MAX20860A_REGULATOR)
+static const struct regulator_desc max20860a_reg_desc[] = {
+ PMBUS_REGULATOR_ONE("vout"),
+};
+#endif
+
+static struct pmbus_driver_info max20860a_info = {
+ .pages = 1,
+ .format[PSC_VOLTAGE_IN] = linear,
+ .format[PSC_VOLTAGE_OUT] = linear,
+ .format[PSC_CURRENT_OUT] = linear,
+ .format[PSC_TEMPERATURE] = linear,
+ .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT |
+ PMBUS_HAVE_STATUS_VOUT |
+ PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_TEMP2 |
+ PMBUS_HAVE_STATUS_TEMP | PMBUS_HAVE_STATUS_INPUT,
+#if IS_ENABLED(CONFIG_SENSORS_MAX20860A_REGULATOR)
+ .num_regulators = 1,
+ .reg_desc = max20860a_reg_desc,
+#endif
+};
+
+static int max20860a_probe(struct i2c_client *client)
+{
+ return pmbus_do_probe(client, &max20860a_info);
+}
+
+static const struct i2c_device_id max20860a_id[] = {
+ {"max20860a"},
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, max20860a_id);
+
+static const struct of_device_id max20860a_of_match[] = {
+ { .compatible = "adi,max20860a" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, max20860a_of_match);
+
+static struct i2c_driver max20860a_driver = {
+ .driver = {
+ .name = "max20860a",
+ .of_match_table = max20860a_of_match,
+ },
+ .probe = max20860a_probe,
+ .id_table = max20860a_id,
+};
+
+module_i2c_driver(max20860a_driver);
+
+MODULE_AUTHOR("Syed Arif <arif.syed@hpe.com>");
+MODULE_AUTHOR("Sanman Pradhan <psanman@juniper.net>");
+MODULE_DESCRIPTION("PMBus driver for Analog Devices MAX20860A");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: hwmon: pmbus: Add Analog Devices MAX20860A
From: Pradhan, Sanman @ 2026-06-01 18:45 UTC (permalink / raw)
To: linux-hwmon@vger.kernel.org
Cc: linux@roeck-us.net, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, noname.nuno@gmail.com, Syed, Arif,
Sanman Pradhan, Conor Dooley
In-Reply-To: <20260601184516.919488-1-sanman.pradhan@hpe.com>
From: Sanman Pradhan <psanman@juniper.net>
Add devicetree binding documentation for the Analog Devices MAX20860A
step-down DC-DC switching regulator with PMBus interface.
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes since v3:
- No change
Changes since v2:
- Drop "maxim,max20860a"; use const: adi,max20860a
Changes since v1:
- Added allOf regulator.yaml reference and unevaluatedProperties
.../bindings/hwmon/pmbus/adi,max20860a.yaml | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
new file mode 100644
index 000000000000..dd238265d462
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pmbus/adi,max20860a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX20860A Step-Down Converter
+
+maintainers:
+ - Sanman Pradhan <psanman@juniper.net>
+
+description: |
+ The MAX20860A is a fully integrated step-down DC-DC switching regulator
+ with PMBus interface for monitoring input/output voltage, output current
+ and temperature.
+
+ Datasheet: https://www.analog.com/en/products/max20860a.html
+
+allOf:
+ - $ref: /schemas/regulator/regulator.yaml#
+
+properties:
+ compatible:
+ const: adi,max20860a
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@40 {
+ compatible = "adi,max20860a";
+ reg = <0x40>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/2] hwmon: (pmbus/max20860a) Add driver for Analog Devices MAX20860A
From: Pradhan, Sanman @ 2026-06-01 18:45 UTC (permalink / raw)
To: linux-hwmon@vger.kernel.org
Cc: linux@roeck-us.net, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, noname.nuno@gmail.com, Syed, Arif,
Sanman Pradhan
From: Sanman Pradhan <psanman@juniper.net>
Add PMBus hwmon driver and DT binding for the Analog Devices MAX20860A
step-down DC-DC switching regulator. The driver provides monitoring of
input/output voltage, output current, and temperature using linear data
format. Optional regulator support is available via Kconfig.
The driver does not modify device write-protection state during probe and
relies on the PMBus core to handle write-protect detection and sysfs
attribute permissions.
Tested on PTX platform with MAX20860A at i2c-195/0x23:
- All sensors (vin, vout, iout, temp1, temp2) read correctly
- Limit attributes correctly read-only (HW write-protect honored)
- Clean dmesg (no probe errors)
Changes since v3:
- Driver: Added optional regulator support via
CONFIG_SENSORS_MAX20860A_REGULATOR
Changes since v2:
- DT binding: Drop "maxim,max20860a" and keep only "adi,max20860a"
- Driver: Drop matching "maxim,max20860a" OF match entry
Changes since v1:
- DT binding: Added allOf regulator.yaml reference and unevaluatedProperties
- Driver: Removed WRITE_PROTECT write from probe
Sanman Pradhan (1):
dt-bindings: hwmon: pmbus: Add Analog Devices MAX20860A
Syed Arif (1):
hwmon: (pmbus/max20860a) Add driver for Analog Devices MAX20860A
.../bindings/hwmon/pmbus/adi,max20860a.yaml | 45 ++++++++++++
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/max20860a.rst | 57 ++++++++++++++++
MAINTAINERS | 8 +++
drivers/hwmon/pmbus/Kconfig | 19 ++++++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/max20860a.c | 68 +++++++++++++++++++
7 files changed, 199 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
create mode 100644 Documentation/hwmon/max20860a.rst
create mode 100644 drivers/hwmon/pmbus/max20860a.c
--
2.34.1
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Andy Shevchenko @ 2026-06-01 18:45 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Simon Schuster, Ethan Nelson-Moore, Wolfram Sang, Peter Zijlstra,
Arnd Bergmann, Dinh Nguyen, linux-doc, devicetree, workflows,
Linux-Arch, dmaengine, linux-i2c, linux-iio, Netdev, linux-pci,
linux-pwm, linux-hardening, linux-kbuild,
linux-csky@vger.kernel.org, Jonathan Corbet, Shuah Khan,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Alex Shi, Yanteng Si, Dongliang Mu, Hu Haowen,
Kees Cook, Oleg Nesterov, Will Deacon, Aneesh Kumar K.V (Arm),
Andrew Morton, Nicholas Piggin, Vinod Koul, Frank Li,
Dave Penkler, Andi Shyti, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lorenzo Pieralisi,
Krzysztof WilczyDski, Andreas Oetken
In-Reply-To: <CANiq72=6oYtHf0Q1NaLXZ+25uQyYbej2xnvUhtgpHyvozhP7_Q@mail.gmail.com>
On Tue, May 19, 2026 at 01:07:46PM +0200, Miguel Ojeda wrote:
> On Tue, May 19, 2026 at 12:41 PM Simon Schuster
> <schuster.simon@siemens-energy.com> wrote:
> >
> > Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
> > unsure about the netiquette (can I simply do so by self-proclamation? At
> > least the git history seems to suggest so...).
>
> Up to the existing maintainer, in general.
>
> I would also suggest changing the support level to "Supported",
> instead of "Maintained" -- that would help justify keeping it in
> mainline.
Supported implies that one gets real money for the job. Is this the case here?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] docs: pt_BR: add translation for kernel development process guides
From: Jonathan Corbet @ 2026-06-01 18:44 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260527155350.202569-1-danielmaraboo@gmail.com>
Daniel Pereira <danielmaraboo@gmail.com> writes:
> Add the Brazilian Portuguese (pt_BR) translation for the
> 'development-process.rst' and '2.process.rst' files under
> the 'process/' directory.
>
> The main 'index.rst' file is also updated to include references
> to the newly translated documents in the toctree.
>
> Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
> ---
> Documentation/translations/pt_BR/index.rst | 1 +
> .../translations/pt_BR/process/2.Process.rst | 520 ++++++++++++++++++
> .../pt_BR/process/development-process.rst | 21 +
> 3 files changed, 542 insertions(+)
> create mode 100644 Documentation/translations/pt_BR/process/2.Process.rst
> create mode 100644 Documentation/translations/pt_BR/process/development-process.rst
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] PM: sleep: Allow disabling DPM watchdog by default
From: Rafael J. Wysocki @ 2026-06-01 18:39 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: Jonathan Corbet, Rafael J. Wysocki, Greg Kroah-Hartman,
Danilo Krummrich, Shuah Khan, Pavel Machek, Len Brown, linux-doc,
linux-kernel, linux-pm, driver-core
In-Reply-To: <20260528103215.505795-1-tzungbi@kernel.org>
On Thu, May 28, 2026 at 12:32 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
>
> Introduce the CONFIG_DPM_WATCHDOG_DEFAULT_ENABLED Kconfig option to
> allow the device suspend/resume watchdog (DPM watchdog) to be disabled
> by default at compile time.
>
> Additionally, introduce the "dpm_watchdog_enabled" boot parameter to
> enable or disable the watchdog at boot time.
>
> This provides flexibility for systems that want the watchdog code
> compiled in but inactive by default, allowing it to be enabled only when
> needed.
>
> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
> ---
> .../admin-guide/kernel-parameters.txt | 8 ++++++++
> drivers/base/power/main.c | 20 +++++++++++++++++++
> kernel/power/Kconfig | 9 +++++++++
> 3 files changed, 37 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 85936e48cf9a..3a919e660137 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1344,6 +1344,14 @@ Kernel parameters
> it becomes active and is searched during signature
> verification.
>
> + dpm_watchdog_enabled=
> + [KNL] Enable or disable the device suspend/resume
> + watchdog (DPM watchdog).
> + Format: {"0" | "1"}
> + 0: disable
> + 1: enable
> + Default value is set by CONFIG_DPM_WATCHDOG_DEFAULT_ENABLED.
> +
> driver_async_probe= [KNL]
> List of driver names to be probed asynchronously. *
> matches with all driver names. If * is specified, the
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index e1b550664bab..4f92905f3edf 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -527,6 +527,20 @@ module_param(dpm_watchdog_all_cpu_backtrace, bool, 0644);
> MODULE_PARM_DESC(dpm_watchdog_all_cpu_backtrace,
> "Backtrace all CPUs on DPM watchdog timeout");
>
> +#ifdef CONFIG_DPM_WATCHDOG_DEFAULT_ENABLED
> +static unsigned int __read_mostly dpm_watchdog_enabled = 1;
> +#else
> +static unsigned int __read_mostly dpm_watchdog_enabled;
> +#endif
> +
> +static int __init dpm_watchdog_setup(char *str)
> +{
> + if (kstrtouint(str, 0, &dpm_watchdog_enabled) == 0)
> + return 1;
> + return 0;
> +}
> +__setup("dpm_watchdog_enabled=", dpm_watchdog_setup);
You might as well use a module parameter to allow this to be set or
clear at run time. Is there a particular reason why you only want it
to be enabled or disabled via the kernel command line?
> +
> /**
> * dpm_watchdog_handler - Driver suspend / resume watchdog handler.
> * @t: The timer that PM watchdog depends on.
> @@ -570,6 +584,9 @@ static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev)
> {
> struct timer_list *timer = &wd->timer;
>
> + if (!dpm_watchdog_enabled)
> + return;
> +
> wd->dev = dev;
> wd->tsk = current;
> wd->fatal = CONFIG_DPM_WATCHDOG_TIMEOUT == CONFIG_DPM_WATCHDOG_WARNING_TIMEOUT;
> @@ -588,6 +605,9 @@ static void dpm_watchdog_clear(struct dpm_watchdog *wd)
> {
> struct timer_list *timer = &wd->timer;
>
> + if (!dpm_watchdog_enabled)
> + return;
> +
> timer_delete_sync(timer);
> timer_destroy_on_stack(timer);
> }
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 05337f437cca..d4cecdb8575e 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -267,6 +267,15 @@ config DPM_WATCHDOG
> captured in pstore device for inspection in subsequent
> boot session.
>
> +config DPM_WATCHDOG_DEFAULT_ENABLED
> + bool "Enable DPM watchdog by default"
> + depends on DPM_WATCHDOG
> + default y
> + help
> + If you say Y here, the DPM watchdog will be enabled by default.
> + If you say N, it will be compiled in but disabled, requiring a
> + boot parameter to activate.
> +
> config DPM_WATCHDOG_TIMEOUT
> int "Watchdog timeout to panic in seconds"
> range 1 120
> --
> 2.54.0.929.g9b7fa37559-goog
>
^ permalink raw reply
* Re: [PATCH v3 3/4] cpufreq: Remove driver default policy->min/max init
From: Rafael J. Wysocki @ 2026-06-01 18:08 UTC (permalink / raw)
To: Pierre Gondois
Cc: linux-kernel, Jie Zhan, Lifeng Zheng, Ionela Voinescu,
Sumit Gupta, Zhongqiu Han, Rafael J. Wysocki, Viresh Kumar,
Jonathan Corbet, Shuah Khan, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm, linux-doc
In-Reply-To: <20260528090913.2759118-4-pierre.gondois@arm.com>
On Thu, May 28, 2026 at 11:10 AM Pierre Gondois <pierre.gondois@arm.com> wrote:
>
> Prior to [1], drivers were setting policy->min/max and
> the value was used as a QoS constraint. After that change,
> the values were only temporarily used: cpufreq_set_policy()
> ultimately overriding them through:
> cpufreq_policy_online()
> \-cpufreq_init_policy()
> \-cpufreq_set_policy()
> \-/* Set policy->min/max */
>
> This patch reinstate the initial behaviour. This will allow
> drivers to request min/max QoS frequencies if desired.
> For instance, the cppc driver advertises a lowest non-linear
> frequency, which should be used as a min QoS value.
>
> To avoid having drivers setting policy->min/max to default
> values which are considered as QoS values (i.e. the reason
> why [1] was introduced), remove the initialization of
> policy->min/max in .init() callbacks wherever the
> policy->min/max values are identical to the
> policy->cpuinfo.min/max_freq.
>
> Indeed, the previous patch ("cpufreq: Set default
> policy->min/max values for all drivers") makes this initialization
> redundant.
>
> The only drivers where these values are different are:
> - gx-suspmod.c (min)
> - cppc-cpufreq.c (min)
> - longrun.c
>
> [1]
> commit 521223d8b3ec ("cpufreq: Fix initialization of min and
> max frequency QoS requests")
>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> Acked-by: Jie Zhan <zhanjie9@hisilicon.com>
sashiko.dev has some feedback on this patch and appears to have a point:
https://sashiko.dev/#/patchset/20260528090913.2759118-1-pierre.gondois%40arm.com
Can you have a look at it please?
> ---
> drivers/cpufreq/amd-pstate.c | 14 ++++++--------
> drivers/cpufreq/cppc_cpufreq.c | 5 ++---
> drivers/cpufreq/cpufreq-nforce2.c | 4 ++--
> drivers/cpufreq/freq_table.c | 7 +++----
> drivers/cpufreq/gx-suspmod.c | 2 +-
> drivers/cpufreq/intel_pstate.c | 3 ---
> drivers/cpufreq/pcc-cpufreq.c | 10 ++++------
> drivers/cpufreq/pxa3xx-cpufreq.c | 5 ++---
> drivers/cpufreq/sh-cpufreq.c | 6 ++----
> drivers/cpufreq/virtual-cpufreq.c | 5 +----
> 10 files changed, 23 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 62b5d995281d2..2f0bb732ea173 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -1086,10 +1086,9 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
>
> perf = READ_ONCE(cpudata->perf);
>
> - policy->cpuinfo.min_freq = policy->min = perf_to_freq(perf,
> - cpudata->nominal_freq,
> - perf.lowest_perf);
> - policy->cpuinfo.max_freq = policy->max = cpudata->max_freq;
> + policy->cpuinfo.min_freq = perf_to_freq(perf, cpudata->nominal_freq,
> + perf.lowest_perf);
> + policy->cpuinfo.max_freq = cpudata->max_freq;
>
> policy->driver_data = cpudata;
> ret = amd_pstate_cppc_enable(policy);
> @@ -1915,10 +1914,9 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
>
> perf = READ_ONCE(cpudata->perf);
>
> - policy->cpuinfo.min_freq = policy->min = perf_to_freq(perf,
> - cpudata->nominal_freq,
> - perf.lowest_perf);
> - policy->cpuinfo.max_freq = policy->max = cpudata->max_freq;
> + policy->cpuinfo.min_freq = perf_to_freq(perf, cpudata->nominal_freq,
> + perf.lowest_perf);
> + policy->cpuinfo.max_freq = cpudata->max_freq;
> policy->driver_data = cpudata;
>
> ret = amd_pstate_cppc_enable(policy);
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 7e7f9dfb7a24c..5abac50df7508 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -660,8 +660,6 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
> * Section 8.4.7.1.1.5 of ACPI 6.1 spec)
> */
> policy->min = cppc_perf_to_khz(caps, caps->lowest_nonlinear_perf);
> - policy->max = cppc_perf_to_khz(caps, policy->boost_enabled ?
> - caps->highest_perf : caps->nominal_perf);
>
> /*
> * Set cpuinfo.min_freq to Lowest to make the full range of performance
> @@ -669,7 +667,8 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
> * nonlinear perf
> */
> policy->cpuinfo.min_freq = cppc_perf_to_khz(caps, caps->lowest_perf);
> - policy->cpuinfo.max_freq = policy->max;
> + policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, policy->boost_enabled ?
> + caps->highest_perf : caps->nominal_perf);
>
> policy->transition_delay_us = cppc_cpufreq_get_transition_delay_us(cpu);
> policy->shared_type = cpu_data->shared_type;
> diff --git a/drivers/cpufreq/cpufreq-nforce2.c b/drivers/cpufreq/cpufreq-nforce2.c
> index fbbbe501cf2dc..831102522ad64 100644
> --- a/drivers/cpufreq/cpufreq-nforce2.c
> +++ b/drivers/cpufreq/cpufreq-nforce2.c
> @@ -355,8 +355,8 @@ static int nforce2_cpu_init(struct cpufreq_policy *policy)
> min_fsb = NFORCE2_MIN_FSB;
>
> /* cpuinfo and default policy values */
> - policy->min = policy->cpuinfo.min_freq = min_fsb * fid * 100;
> - policy->max = policy->cpuinfo.max_freq = max_fsb * fid * 100;
> + policy->cpuinfo.min_freq = min_fsb * fid * 100;
> + policy->cpuinfo.max_freq = max_fsb * fid * 100;
>
> return 0;
> }
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index 5b364d8da4f92..ea994647abc88 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -49,16 +49,15 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
> max_freq = freq;
> }
>
> - policy->min = policy->cpuinfo.min_freq = min_freq;
> - policy->max = max_freq;
> + policy->cpuinfo.min_freq = min_freq;
> /*
> * If the driver has set its own cpuinfo.max_freq above max_freq, leave
> * it as is.
> */
> if (policy->cpuinfo.max_freq < max_freq)
> - policy->max = policy->cpuinfo.max_freq = max_freq;
> + policy->cpuinfo.max_freq = max_freq;
>
> - if (policy->min == ~0)
> + if (min_freq == ~0)
> return -EINVAL;
> else
> return 0;
> diff --git a/drivers/cpufreq/gx-suspmod.c b/drivers/cpufreq/gx-suspmod.c
> index d269a4f26f98e..d40c9e0bbb740 100644
> --- a/drivers/cpufreq/gx-suspmod.c
> +++ b/drivers/cpufreq/gx-suspmod.c
> @@ -421,7 +421,7 @@ static int cpufreq_gx_cpu_init(struct cpufreq_policy *policy)
> policy->min = maxfreq / max_duration;
> else
> policy->min = maxfreq / POLICY_MIN_DIV;
> - policy->max = maxfreq;
> +
> policy->cpuinfo.min_freq = maxfreq / max_duration;
> policy->cpuinfo.max_freq = maxfreq;
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 1f093e3464301..dfc1e321f9e02 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -3049,9 +3049,6 @@ static int __intel_pstate_cpu_init(struct cpufreq_policy *policy)
> policy->cpuinfo.max_freq = READ_ONCE(global.no_turbo) ?
> cpu->pstate.max_freq : cpu->pstate.turbo_freq;
>
> - policy->min = policy->cpuinfo.min_freq;
> - policy->max = policy->cpuinfo.max_freq;
> -
> intel_pstate_init_acpi_perf_limits(policy);
>
> policy->fast_switch_possible = true;
> diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
> index ac2e90a65f0c4..0f185a13577f8 100644
> --- a/drivers/cpufreq/pcc-cpufreq.c
> +++ b/drivers/cpufreq/pcc-cpufreq.c
> @@ -551,13 +551,11 @@ static int pcc_cpufreq_cpu_init(struct cpufreq_policy *policy)
> goto out;
> }
>
> - policy->max = policy->cpuinfo.max_freq =
> - ioread32(&pcch_hdr->nominal) * 1000;
> - policy->min = policy->cpuinfo.min_freq =
> - ioread32(&pcch_hdr->minimum_frequency) * 1000;
> + policy->cpuinfo.max_freq = ioread32(&pcch_hdr->nominal) * 1000;
> + policy->cpuinfo.min_freq = ioread32(&pcch_hdr->minimum_frequency) * 1000;
>
> - pr_debug("init: policy->max is %d, policy->min is %d\n",
> - policy->max, policy->min);
> + pr_debug("init: max_freq is %d, min_freq is %d\n",
> + policy->cpuinfo.max_freq, policy->cpuinfo.min_freq);
> out:
> return result;
> }
> diff --git a/drivers/cpufreq/pxa3xx-cpufreq.c b/drivers/cpufreq/pxa3xx-cpufreq.c
> index 50ff3b6a69000..06b27cbc59d6a 100644
> --- a/drivers/cpufreq/pxa3xx-cpufreq.c
> +++ b/drivers/cpufreq/pxa3xx-cpufreq.c
> @@ -185,9 +185,8 @@ static int pxa3xx_cpufreq_init(struct cpufreq_policy *policy)
> int ret = -EINVAL;
>
> /* set default policy and cpuinfo */
> - policy->min = policy->cpuinfo.min_freq = 104000;
> - policy->max = policy->cpuinfo.max_freq =
> - (cpu_is_pxa320()) ? 806000 : 624000;
> + policy->cpuinfo.min_freq = 104000;
> + policy->cpuinfo.max_freq = (cpu_is_pxa320()) ? 806000 : 624000;
> policy->cpuinfo.transition_latency = 1000; /* FIXME: 1 ms, assumed */
>
> if (cpu_is_pxa300() || cpu_is_pxa310())
> diff --git a/drivers/cpufreq/sh-cpufreq.c b/drivers/cpufreq/sh-cpufreq.c
> index 642ddb9ea217e..3c99d7009cbe2 100644
> --- a/drivers/cpufreq/sh-cpufreq.c
> +++ b/drivers/cpufreq/sh-cpufreq.c
> @@ -124,10 +124,8 @@ static int sh_cpufreq_cpu_init(struct cpufreq_policy *policy)
> dev_notice(dev, "no frequency table found, falling back "
> "to rate rounding.\n");
>
> - policy->min = policy->cpuinfo.min_freq =
> - (clk_round_rate(cpuclk, 1) + 500) / 1000;
> - policy->max = policy->cpuinfo.max_freq =
> - (clk_round_rate(cpuclk, ~0UL) + 500) / 1000;
> + policy->cpuinfo.min_freq = (clk_round_rate(cpuclk, 1) + 500) / 1000;
> + policy->cpuinfo.max_freq = (clk_round_rate(cpuclk, ~0UL) + 500) / 1000;
> }
>
> return 0;
> diff --git a/drivers/cpufreq/virtual-cpufreq.c b/drivers/cpufreq/virtual-cpufreq.c
> index 4159f31349b16..dc78b74409af4 100644
> --- a/drivers/cpufreq/virtual-cpufreq.c
> +++ b/drivers/cpufreq/virtual-cpufreq.c
> @@ -164,10 +164,7 @@ static int virt_cpufreq_get_freq_info(struct cpufreq_policy *policy)
> policy->cpuinfo.min_freq = 1;
> policy->cpuinfo.max_freq = virt_cpufreq_get_perftbl_entry(policy->cpu, 0);
>
> - policy->min = policy->cpuinfo.min_freq;
> - policy->max = policy->cpuinfo.max_freq;
> -
> - policy->cur = policy->max;
> + policy->cur = policy->cpuinfo.max_freq;
> return 0;
> }
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [RFC PATCH 0/5] mm, swap: Virtual Swap Space (Swap Table Edition)
From: Nhat Pham @ 2026-06-01 18:06 UTC (permalink / raw)
To: Kairui Song
Cc: Liam.Howlett, akpm, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, lance.yang,
lenb, linux-doc, linux-kernel, linux-mm, linux-pm,
lorenzo.stoakes, matthew.brost, mhocko, muchun.song, npache,
pavel, peterx, peterz, pfalcato, rafael, rakie.kim,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel, haowenchao22
In-Reply-To: <CAMgjq7BhOn48xEyC=2j837R7qddfjeBVHMiRqdx8no4ZEBpBLg@mail.gmail.com>
On Mon, Jun 1, 2026 at 10:45 AM Kairui Song <ryncsn@gmail.com> wrote:
>
> On Mon, Jun 1, 2026 at 11:57 PM Nhat Pham <nphamcs@gmail.com> wrote:
> >
> > On Mon, Jun 1, 2026 at 12:34 AM Kairui Song <ryncsn@gmail.com> wrote:
> > >
> > > For the format part, PHYS don't need that much bits I think,
> > > so by slightly adjust the format vswap device could be share
> > > mostly the same format with ordinary device.
> > >
> > > For example typical modern system don't have a address space larger
> > > than 52 bit. (Even with full 64 bits used for addressing, shift it
> > > by 12 we get 52). Plus 5 for type, you get 57, so you can have a
> > > marker that should work as long as it shorter than 1000000 for PHYS,
> > > and shared for all table format since it's not in conflict with
> > > anything. You have also use a few extra bits so a single swap space
> > > can be 8 times larger than RAM space, and since we can help
> > > multiple swap type I think that should be far than enough?
> > >
> > > Then you have Shadow back at 001, and zero bit in shadow. The only
> > > special one is Zswap, which will be 100 now, and that's exactly the
> > > reserved pointer format in current swap table format, on seeing
> > > si->flags & VSWAP && is_pointer(swp_tb) you know that's zswap :)
> >
> > Are you suggesting we merge the virtual table with main swap table?
> >
> > Man, I'd love to do this. There is a problem though - we have a case
> > where we occupy both backing physical swap AND swap cache. Do you
> > think we can fit both the physical swap slot handle and the swap cache
> > PFN into the same slot in virtual table? Maybe with some expanding...?
>
> I don't really get why we would need to do that? If you put the PFN
> info in the virtual / upper layer, then the count info, locking, and
> all swap IO synchronization (via folio lock), dup (current protected
> by ci lock / folio lock), and allocation (folio_alloc_swap), are all
> handled in this layer.
>
> The physical / lower layer will just hold a reverse entry on
> folio_realloc_swap, or no entry at all (no physical layer used, zswap,
> or after swap allocation but before IO) right?
>
> Looking up the actual folio from the physical layer will be a bit
> slower since it needs to resolve the reverse entry, but the only place
> we need to do that is things like migrate, compaction (none of them
> exist yet) which seems totally fine?
All of this is correct, but consider swaping in a vswap entry backed
by pswap. There are cases where you still want to maintain the pswap
slots around backing vswap entry, while having the swap cache folio as
well.
For e.g, at swap in time, we add the folio into the swap cache. First
of all, we need to hold on to the physical swap slot for IO step. But
even after IO succeeds, there are cases where you would still like to
keep physical swap slots around (for e.g, to avoid swapping out again
if the folio is only speculatively fetched).
So you have to make sure we have space for both the physical swap
slot, and the swap cache folio's PFN at the same time for each vswap
entry. So we still need the vtable extension (well maybe the other
approach I mentioned could work, but I'm not 100% sure).
>
> > > This could be imporved by per-si percpu cluster. Both YoungJun's
> > > tiering and Baoquan's previous swap ops mentioned this is needed,
> > > and now vswap also need that. If the vswap is also a si, then it will
> > > make use of this too.
> >
> > Yeah I made the same recommendation when I review swap tier last week:
> >
> > https://lore.kernel.org/all/CAKEwX=N2XcMHN1jatppOk6wnmz-Shab5XMtTtzgYOzRvU_6YFw@mail.gmail.com/
> >
> > I like it, but yeah it will be complicated. That said, I think not
> > fixing the fast path for tiering/vswap will seriously restrict their
> > usefulness. We don't want to go back to the old swap allocator days :)
>
> Thanks. Not too complicated, actually our internal kernel
> implementation still using si->percpu cluster, and use a counter for
> the rotation and each order have a counter :P, it's a bit ugly but
> works fine. It still serves pretty well just like the global percpu
> cluster, YoungJun's previous per ci percpu cluster also still provides
> the fast path, many ways to do that.
Sounds like something that should be upstreamed? ;)
I was concerned that you might deem the overhead too high (so I came
up with the per-tier percpu caching), but honestly I like it a lot.
>
> >
> > >
> > > YoungJun posted this a few month before:
> > > https://lore.kernel.org/linux-mm/20260131125454.3187546-5-youngjun.park@lge.com/
> > >
> > > The concern is that some locking contention could be heavier, or maybe
> > > that's just a hypothetical problem though.
> >
> > I don't think it's hypothetical. At least with vswap, it's very easy
> > to get into a state where the shared per-cpu cache gets invalidated
> > constantly if phys swap and vswap allocation alternates (which is
> > actually very possible under heavy memory pressure), hammering the
> > slow paths...
>
> I mean if the per-cpu cache is moved to si level, then whoever enters
> the allocation path of a si will almost always get a stable percpu
> cache to use, even if the last used si changes.
>
> We might better have a more explicit per si fast path for that. The
> plist rotation should better be done in a different (will be even
> better if lockless) way.
Exactly! That's what I'm thinking too. Basically I'm special-casing
for vswap here, but if you're happy with generalizing this for every
si I'm happy with it.
>
> >
> > >
> > > >
> > > > - Runtime enable/disable of the vswap device. To be honest, I don't
> > > > know if there is a value in this. My preference is vswap can be
> > > > optimized to the point that any overhead is negligible. Failing that,
> > > > maybe we can come up with some simple heuristics that automatically
> > > > decides for users?
> > > >
> > > > In this RFC, CONFIG_VSWAP=y means the vswap device is always created at
> > > > boot, and CONFIG_VSWAP=n means the vswap device is never created. This
> > > > *might* be enough just on its own.
> > > >
> > > > Is a runtime knob (sysfs or sysctl) worth the complexity beyond
> > > > these heuristics? I'm not sure yet. Maintaining both cases
> > >
> > > I checked the code and I think it's not hard to do, patch 1 already
> > > handling the meta data dynamically, everything will still just work
> > > even if you remove vswap at runtime. The rest of patches need adaption
> > > but might not end up being complex, it other comments here
> > > are considered.
> >
> > Yeah, it's not terribily hard to do. I'm more wondering if it's worth
> > the effort, both for the implementer and the user :)
> >
> > As I said here, if we want vswap, just enable it at boot time and get
> > a vast (but dynamic) device. We can make it optional per-cgroup
> > through Youngjun's interface, and that would be good enough?
> >
> > >
> > > For patch 2, a few routines like vswap_can_swapin_thp seems not
> > > needed or should be moved to __swap_cache_alloc? VSWAP_FOLIO is
> > > same as swap cache folio check, which is already covered. Same for
> > > zero checking, and VSWAP_NONE which is same as swap count check
> > > I think. That way we not only save a lot of code, we also no
> > > longer need to treat vswap specially.
> >
> > Unfortunately, I think a lot of this complexity is still needed. Vswap
> > adds a new layer, which means new complications :)
> >
> > For instance, I think you still need vswap_can_swapin_thp. It
> > basically enforces that the backend must be something
> > swap_read_folio() can handle. That means:
> >
> > 1. No zswap.
> >
> > 2. No mixed backend.
>
> If mixed backend means phys vs zero vs zswap, then we already have
> part of that covered with the current swap cache except for the phys
> part (zswap part seems very doable with fujunjie's work).
> swap_cache_alloc_folio will ensure there is no mixed zerobit, it can
> be easily extended to ensure there is no mixed zswap as well
> (according to what I've learned from fujunjie's code). Similar logic
> for phys detection I think.
Yeah it's basically generalizing that check, and handle the case where
we can have indirection.
I mean I can open-code it, but it has to be there :) And I figure it
might be useful to check this opportunistically (at swap_pte_batch,
even if it's not guaranteed to be correct down the line) before we
even attempt to allocate a large folio etc. to avoid large folio
allocation.
>
> > > For memcg table allocation, on demand seems a good idea, and actually
> > > we are not far from there, I tried to generalize the
> > > alloc-then-retry-sleep-alloc in swap_alloc_table but still not generic
> > > enough I guess.. Good new is the allocation of the table is already
> > > kind of ondemand, just need to split the detection of these two kind
> > > of table.
> >
> > I have a prototype of this, but I have not tested, so I do not want to
> > send it out. :)
> >
> > TLDR is - I still want to record the memcg for vswap (just not charge
> > it towards the counter). So we still need memcg_table at both level,
> > generally - just not allocating until needed (basically if a physical
> > swap slot in the cluster is directly mapped into PTE). You can kinda
> > tell, since you pass the folio into the allocation path - with some
> > care you can distinguish between:
> >
> > 1. Virtual swap, or directly maped physical swap -> need memcg_table
> >
> > 2. Physical swap, backing vswap -> does not memcg_table.
> >
> > Another alternative is you can defer this allocation until the point
> > where you have to do the charging action. But then you have to be
> > careful with failure handling, and need to backoff ya di da di da.
> > Funsies.
> >
> > I think I did a mixed of these 2 strategies. Anyway, I'll include the
> > patch in v2 (if folks like this approach).
> >
> > >
> > > Mean while I also remember we once discussed about splitting the
> > > accounting for vswap / physical swap? If we went that approach we
> > > don't need to treat memcg_table specially.
> >
> > For the charging behavior, I already have a patch for it actually in
> > this series (just not the dynamic allocation of the memcg_table field
> > yet).
> >
> > Basically:
> >
> > 1. For vswap entry, not backed by phys swap: record swap memcg, hold
> > reference to pin the memcg, but not charging towards swap.current.
>
> Maybe you don't need to record memcg here since folio->memcg already
> have that info?
>
> I previously had a patch:
> https://lore.kernel.org/linux-mm/20260220-swap-table-p4-v1-7-104795d19815@tencent.com/
>
> The defers the recording of memcg, the behavior is almost identical to
> before, but charging & recording should be cleaner and you don't need
> to record memcg at allocation time hence maybe reduce the possibility
> of pinning a memcg. I didn't include that in P4 just to reduce LOC,
> maybe can be resent or included.
That works-ish when the folio is sitll in swap cache, but say if it's
vswap backed by zswap (and the swap cache folio has been reclaimed),
you need a place to store the memcg, no?
Just seems cleaner to centralize this info at vswap layer when it is
presented, for now anyway, rather than juggling this on a per-backend
basis.
>
> > 2. For phys swap backing vswap: charging towards swap.current, but
> > does not record the memcg in its memcg_table, nor does it hold
> > reference to memcg (its vswap entry holds the reference already)
> >
> > 2. For phys swap directly mapped to PTE: charges, records, and holds reference.
> >
> > The motivation here is I do not want vswap entry to shares the same
> > limit as phys swap counter. If we think of it as "infinite" or
> > "dynamic", it should not be capped at all, but even if it is charged,
> > it should be something separate.
>
> Good to know, it's not too messy to make everything dynamic, but if
> our ultimate goal is to account for them separately, maybe we can save
> some effort here.
It's not terrible, TBH.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox