summaryrefslogtreecommitdiff
path: root/tools/lib/python
diff options
context:
space:
mode:
authorMichael Kelley <mhklinux@outlook.com>2026-02-20 08:40:45 -0800
committerWei Liu <wei.liu@kernel.org>2026-04-14 04:42:02 +0000
commit1c80dd81cac1865bbd6049bb93068a41ffb19845 (patch)
treef93a1db345362eda78ebf43fc51523a07bab4161 /tools/lib/python
parent028ef9c96e96197026887c0f092424679298aae8 (diff)
Drivers: hv: vmbus: Limit channel interrupt scan to relid high water mark
When checking for VMBus channel interrupts, current code always scans the full SynIC receive interrupt bit array to get the relid of the interrupting channels. The array has HV_EVENT_FLAGS_COUNT (2048) bits. But VMs rarely have more than 100 channels, and the relid is typically a small integer that is densely assigned by the Hyper-V host. It's wasteful to scan 2048 bits when it is highly unlikely that anything will be found past bit 100. The waste is double with Confidential VMBus because there are two receive interrupt arrays that must be scanned: one for the hypervisor SynIC and one for the paravisor SynIC. Improve the scanning by tracking the largest relid that has been offered by the Hyper-V host. Then when checking for VMBus channel interrupts, only scan up to this high water mark. When channels are rescinded, it's not worth the complexity to recalculate the high water mark. Hyper-V tends to reuse the rescinded relids for any new channels that are subsequently added, and the performance benefit of exactly tracking the high water mark would be minimal. Signed-off-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Roman Kisel <vdso@mailbox.org> Reviewed-by: Roman Kisel <vdso@mailbox.org> Signed-off-by: Wei Liu <wei.liu@kernel.org>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions