mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


             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®