[PATCHv2] nvme-pci: allow unmanaged interrupts
Sagi Grimberg
sagi at grimberg.me
Sun May 12 07:16:13 PDT 2024
>> Everyone expects nvme performance will suffer. IO latency and CPU
>> efficieny are not everyone's top priority, so allowing people to
>> optimize for something else seems like a reasonable request.
> I guess more people may be interested in 'something else', care to share
> them in the commit log, cause nvme is going to support it.
I don't have a special interest in this, but I can share what I heard
several
times. The use-case is that people want to dedicate a few cores to handle
interrupts so they know it does not take cpu time from their application
threads
that are running (usually pinned to different cores).
The app threads isolation is more important to them than affinity to the
device...
>
>>
>>> Is there any benefit to use unmanaged irq in this way?
>> The immediate desire is more predictable scheduling on a subset of CPUs
>> by steering hardware interrupts somewhere else. It's the same reason
>> RDMA undid managed interrupts.
>>
>> 231243c82793428 ("Revert "mlx5: move affinity hints assignments to generic code")
> The above commit only mentions it becomes not flexible since user can't
> adjust irq affinity any more.
>
> It is understandable for network, there is long history people need to adjust
> irq affinity from user space.
I suspect that the reasoning is similar to nvme as well.
More information about the Linux-nvme
mailing list