Re: [RFC PATCH 0/3] nvme-pci: yield completions under scheduler pressure

[Naman Jain <namjain@linux.microsoft.com>]

On 10/12/2026 12:30 PM, Fengnan wrote:
> 在 2026/10/12 14:48, Naman Jain 写道:
>>
>>
>> On 10/9/2026 5:06 PM, Fengnan wrote:
>>> Hi Naman:
>>>
>>> This is an issue I hadn’t noticed before.
>>> I'll take a closer look at this issue later.
>>>
>>> Regarding testing, there are a few points to note:
>>> 1. My patch has been updated to V2, https://lore.kernel.org/linux-nvme/20260826061546.56006-1-changfengnan@bytedance.com/
>>> 2. In my experience, when do performance tests, it’s best to do precondition
>>> first and then execute an ABBA test; this ensures reliable results.
>>> 3. IIRC, disabling interrupts in the QEMU kernel does not actually disable hardware
>>> interrupts; QEMU still handles them, which has a significant impact on performance testing.
>>> Perhaps you could test this on a physical machine.
>>>
>>> Also, I’d like to ask: does this softlockup issue only occur on QEMU+ARM?
>>> or does it also occur on x86 physical machines?
>>> Have you tried enabling the “Posted Interrupt” feature in VM? Maybe this will solve
>>> this problem in VM.
>>>
>>> Thanks.
>>
>> Hi Fengnan,
>> Thanks for the suggestion.
>>
>> I was using QEMU just for sanity, all the test results are based on experiments in an Azure ARM64 Hyper-V VM. I could not create enough load on my local QEMU VM to cause a lockup, so I am relying only on the Azure VM I have. I would not rule out x86 for this issue, as we have seen spurious lockups in the fleet, which are more common on certain SKUs, but my current experiments are limited to arm64. The proposed solution should solve it for both.
> 
> I set up a test environment on my own this morning.
> Although I wasn't able to reproduce the soft lockup issue, I did observe
> I/O latency of several hundred milliseconds.

Acked.

> 
>>
>> The guest exposes a GICv3 CPU interface and Hyper-V vPCI maps the NVMe MSI-X vectors as guest GIC SPIs. I do not see an ITS, LPIs/vLPIs, GICv4 VPEs, or another direct virtual interrupt injection interface exposed to the guest. Also, posted/direct interrupts would reduce host-to-guest interrupt injection overhead, but the lockup here occurs after delivery, while nvme_irq() repeatedly drains completion queues in guest hardirq context. So I would not expect posted interrupts alone to provide the missing scheduling boundary.
> 
> I'm thinking that adding a scheduling check to my patch should also resolve
> this issue.
> That would be simpler and more acceptable, we can work together to refine it.
> 
> Thanks.
> 

Sure, happy to collaborate. Please include me in any new discussions you 
have in your patch. And let's hear what Christoph and other maintainers 
have to say, and then we can converge on that approach going forward.


Regards,
Naman