From: Emerson Busson <emersonbusson@gmail.com>
To: linux-hyperv@vger.kernel.org
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, linux-kernel@vger.kernel.org,
emersonbusson@gmail.com
Subject: [PATCH 0/2] hv: vmbus: prevent control-plane starvation and order-7 ring deadlocks under memory pressure
Date: Thu, 17 Sep 2026 22:40:15 -0300 [thread overview]
Message-ID: <20260918014017.2536753-1-emersonbusson@gmail.com> (raw)
Under Microsoft Hyper-V and WSL2 virtual machine environments, heavy
memory pressure and memory tiering workloads (e.g. swap-heavy tasks,
containerized compilation, in-memory databases) frequently expose
guest kernels to starvation across two critical VMBus mechanisms:
1. Control-plane and heartbeat starvation:
During aggressive direct reclaim, available pages drop below safety
watermarks. Atomic allocations (GFP_ATOMIC) required by synthetic
VMBus packets, virtual network switches (netvsc), and balloon
management fail. When the guest fails to service host heartbeats,
the Windows Host Compute System (HCS) watchdog presumes a guest
hard lock, triggering abrupt virtual switch teardowns
(Hyper-V-VmSwitch Event 102/291) and ungracefully restarting the VM
prior to any Linux OOM killer intervention. Concurrently, host
balloon driver requests exacerbate exhaustion.
2. High-order contiguous allocation failures:
Dynamically instantiated VMBus sub-channels (e.g., synthetic SCSI,
network, and vsock) invoke vmbus_alloc_ring(), requiring order-7
(512 KiB) contiguous physical pages via alloc_pages(GFP_KERNEL |
__GFP_ZERO, order). Severe buddy allocator fragmentation causes
alloc_pages() to fail with -ENOMEM even when ample virtual memory
exists. On WSL2, this directly manifests as userspace communication
failures (e.g. "accept4 failed 110: Connection timed out" on vsock
control planes).
This series resolves both issues:
- Patch 1/2 dynamically establishes a memory headroom floor for
vm.min_free_kbytes during late_initcall (clamped between 64 MiB and
512 MiB based on 3.125% of total guest RAM), safeguarding atomic
allocations and VMBus heartbeats. It also defers balloon driver
inflation when available memory drops below totalram_pages() / 32 to
avoid competing with direct reclaim.
- Patch 2/2 introduces a fallback to vzalloc_node() / vzalloc() in
vmbus_alloc_ring() when high-order physical allocation fails, adapts
hv_ringbuffer_init() using vmalloc_to_page() for double-mapped ring
wraparounds, and preserves Confidential VM (CoCo) guest memory
re-encryption guarantees in vmbus_free_ring().
Verification & Testing:
Tested and validated against Microsoft WSL2 rolling-lts 6.18 kernel
under multi-tier memory pressure (13.66 GB/s transfer bandwidth across
ZRAM, VRAM, and SSD tiers), verifying zero kernel panics, zero HCS
disconnects, and flawless vsock channel open resilience.
Related issue discussions:
- https://github.com/microsoft/WSL/issues/41634
- https://github.com/microsoft/WSL/issues/40795
Emerson Busson (2):
hv: vmbus: prevent control-plane starvation and balloon thrash under
memory pressure
hv: vmbus: add virtual memory fallback for ring buffer allocations
under memory pressure
drivers/hv/channel.c | 46 ++++++++++++++++++++++++++++++++++-----
drivers/hv/hv_balloon.c | 12 ++++++++++
drivers/hv/hv_common.c | 32 +++++++++++++++++++++++++++
drivers/hv/hyperv_vmbus.h | 2 +-
drivers/hv/ring_buffer.c | 19 +++++++++++-----
include/linux/hyperv.h | 2 ++
6 files changed, 101 insertions(+), 12 deletions(-)
--
2.43.0
next reply other threads:[~2026-09-18 1:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 1:40 Emerson Busson [this message]
2026-09-18 1:40 ` [PATCH 1/2] hv: vmbus: prevent control-plane starvation and balloon thrash " Emerson Busson
2026-09-18 1:40 ` [PATCH 2/2] hv: vmbus: add virtual memory fallback for ring buffer allocations " Emerson Busson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260918014017.2536753-1-emersonbusson@gmail.com \
--to=emersonbusson@gmail.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®