The managed_irq documentation is a bit difficult to understand. Rephrase the current text and add the latest changes how managed_irq CPU sets are handled. Isolated CPUs and housekeeping CPUs are grouped into sets and the possibility of stalls if all housekeeping CPUs are offlined in a set. Signed-off-by: Daniel Wagner <wagi@xxxxxxxxxx> --- Documentation/admin-guide/kernel-parameters.txt | 46 +++++++++++++------------ 1 file changed, 24 insertions(+), 22 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3872bc6ec49d63772755504966ae70113f24a1db..e4bf1fc984943c1d4938dffb85d97da05010a325 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2460,28 +2460,30 @@ "number of CPUs in system - 1". managed_irq - - Isolate from being targeted by managed interrupts - which have an interrupt mask containing isolated - CPUs. The affinity of managed interrupts is - handled by the kernel and cannot be changed via - the /proc/irq/* interfaces. - - This isolation is best effort and only effective - if the automatically assigned interrupt mask of a - device queue contains isolated and housekeeping - CPUs. If housekeeping CPUs are online then such - interrupts are directed to the housekeeping CPU - so that IO submitted on the housekeeping CPU - cannot disturb the isolated CPU. - - If a queue's affinity mask contains only isolated - CPUs then this parameter has no effect on the - interrupt routing decision, though interrupts are - only delivered when tasks running on those - isolated CPUs submit IO. IO submitted on - housekeeping CPUs has no influence on those - queues. + Isolate CPUs from IRQ-related work for drivers + that support managed interrupts, ensuring no + IRQ work is scheduled on the isolated CPUs. The + kernel manages the affinity of managed + interrupts, which cannot be changed via the + /proc/irq/* interfaces. + + Since isolated CPUs do not handle IRQ work, the + work is forwarded to housekeeping CPUs. + Housekeeping and isolated CPUs are grouped into + sets, ensuring at least one housekeeping CPU is + available per set. Consequently, if all + housekeeping CPUs in a set are offlined, there + will be no CPU available to handle IRQ work for + the isolated CPUs. Therefore, users should + offline all isolated CPUs before offlining the + housekeeping CPUs in a set to avoid stalls. + + The block layer ensures that no I/O is + scheduled on isolated CPU, except when user + applications running on the isolated CPUs issue + I/O requests. In this case the I/O is issued + from the isolated CPU and the IRQ related work + is forwared to a housekeeping CPU. The format of <cpu-list> is described above. -- 2.47.1
