summaryrefslogtreecommitdiff
path: root/include/asm-m32r/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>2026-04-01 13:02:32 +0200
committerJonathan Corbet <corbet@lwn.net>2026-04-11 07:07:02 -0600
commitbb6a85b4b652f8424b5a28c2c445ded41ded51d0 (patch)
treeac0065e934b651b1ac145e43fc6226101ca69440 /include/asm-m32r/git@git.tavy.me:linux.git
parent64cb68766fc8679626b422319b8b678d5792bfbf (diff)
Documentation: Add managed interrupts
I stumbled upon "isolcpus=managed_irq" which is the last piece which can only be handled by isolcpus= and has no runtime knob. I knew roughly what managed interrupts should do but I lacked some details how it is used and what the managed_irq sub parameter means in practise. This documents what we have as of today and how it works. I added some examples how the parameter affects the configuration. Did I miss something? Given that the spreading as computed group_cpus_evenly() does not take the mask of isolated CPUs into account I'm not sure how relevant the managed_irq argument is. The virtio_scsi driver has no way to limit the interrupts and I don't see this for the nvme. Even if the number of queues can be reduced to two (as in the example) it is still spread evenly in the system instead and the isolated CPUs are not taken into account. To make this worse, you can even argue further whether or not the application on the isolated CPU wants to receive the interrupt directly or would prefer not to. Given all this, I am not sure if it makes sense to add 'io_queue' to the mix or if it could be incorporated into 'managed_irq'. One more point: Given that isolcpus= is marked deprecated as of commit b0d40d2b22fe4 ("sched/isolation: Document isolcpus= boot parameter flags, mark it deprecated") and the 'managed_irq' is evaluated at device's probe time it would require additional callbacks to re-evaluate the situation. Probably for 'io_queue', too. Does is make sense or should we simply drop the "deprecation" notice and allowing using it long term? Dynamic partitions work with cpusets, there this (managed_irq) limitation but is it really? And if static partition is the use case why bother. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Ming Lei <tom.leiming@gmail.com> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Acked-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260401110232.ET5RxZfl@linutronix.de>
Diffstat (limited to 'include/asm-m32r/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions