From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.176 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793470243; b=0wCWN3pGe948A+upF3vbqca6ajq2xmDN/u9apE6kXgRpEeW2LQ/qxbAtM9xSnV5OF6xf 8n0CyXA2BygCyjWM+sVQf/2eCsJT8jcJAWR9+S+dDpTOMn9WLq992t3V13tj0bJLUPU/7 lZG6r/ACkrKoWu07pJDJ5Umb6rK1NRy/8yb1JqDKXbSBWY95vaSOP1zniRv5rv7pSzzj2 OrZ8OaxLIiWk6iu1A5Nq2+xFVVJQtsiMKzaQ5Cf/wHJtydaNfRIv/KnxFoyLTaNjQlq2E tHCFbT2/r3zkC9L5i3hxucanZp6VzlIVrFfdMujQob5oEmiDA6h/h17bRpH1Uga15Jw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793470243; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:From:To:Cc:Subject:Date:Message-ID: X-Mailer:MIME-Version:Content-Transfer-Encoding; bh=gasBqSAnV3vmniUcbI9YXZHfc6XeNj1p84CcMezMQsQ=; b=A4E/RN5YR1RELbpKma4SFYZQcXcoCQTfR1rgKpCCzBsTqw4hHpHn8l8Z3+18r34FYdw2 Du2KV++p4u3S2FBcNtuKZ8PGRf0LSyemyB37HS2ic1QDwITH13PEOoXm4E2vdNMynTAzM Aa3IdQJjnjz+BEuy3IQisO+boA3b+6zSgrDH+6Vmcn2vXyh+EP4ufaJ0zYnTJajptELAp lrsJg91AWNksxdQgrs/VtkoYbBsPJqT49ESAQhz3uKlzimOShWJgMPx7gOn/VgdMtkJRB FK66kitW9wjxBVGFQRCAhKjONNSO+R46gicaUww0pJ82KtcZGetI9JdyyWKacAywedQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=I2ElcM0L; arc=none smtp.remote-ip=91.218.175.176 Received: from mta0.migadu.com (out-176.mta0.migadu.com [91.218.175.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD0BC606A31D for ; Sat, 31 Oct 2026 18:10:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org BD0BC606A31D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=I2ElcM0L X-Envelope-To: linux-mmc@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=HAspga3z+Ons/LXwua+up+NOY/bhAKhpJxJzMMgbKTU=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793470239; v=1; x=1794075039; b=I2ElcM0LLwWgAoH4NlKM8Y3TN7Lvpo6kQu370vl2ybS2DjV0HT/+yBwpf3GND434jBQupE9b p74O1fsOybSyUtcj+kUN1cpRHylOPU7FhjgDsnCTpNIEflMb57Gz/Lag2OpS2HXZoE+EhEXAXwv B4Vs3AV+smssBLCt0M2XWx2I= X-Envelope-To: linux-mmc@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 5926407d61842773; Sat, 31 Oct 2026 18:10:39 +0000 X-Mizu-Trace-ID: 5926407d61842773 X-Migadu-Flow: FLOW_OUT From: Shakeel Butt To: "Michael S . Tsirkin" , Jason Wang , =?UTF-8?q?Eugenio=20P=C3=A9rez?= Cc: Meta kernel team , cgroups@vger.kernel.org, linux-mmc@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] vhost_task: do the return-to-userspace work between work items Date: Sat, 31 Oct 2026 11:10:04 -0700 Message-ID: <20261031181004.4193627-1-shakeel.butt@linux.dev> X-Mailer: git-send-email 2.53.0 X-Mailing-List: linux-mmc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A vhost task is a user worker: a thread of a user process that runs only kernel code. It never returns to userspace, so it never runs the work that is queued for the way back. resume_user_mode_work() does that work when TIF_NOTIFY_RESUME is set. For a vhost task this means: - memory.high is handled at the wrong time. When a charge goes over memory.high, the task counts the pages, and should reclaim, and sleep if needed, on its way back to userspace. A vhost task only reclaims when more than a batch of pages has built up and the charge can block. Then it reclaims and sleeps in the middle of the charge, maybe while it holds a lock. vhost-scsi, for example, can fault in guest memory while it holds vq->mutex. If the charges can't block, nothing is done at all, and the count keeps growing. - Block cgroup throttling never runs. blkcg_schedule_throttle() asks for it, but only resume_user_mode_work() acts on it. - Task work queued with TWA_RESUME, like a deferred fput() or a NUMA balancing scan, waits until the task gets a signal or exits. io_uring workers had the same problem, and io_run_task_work() calls resume_user_mode_work() for them. Do the same in vhost_task_fn(): if TIF_NOTIFY_RESUME is set, call resume_user_mode_work() at the top of the loop. That is between work items, no locks are held there, and the task is running. Passing a NULL regs is fine, io_uring and KVM already do it. This covers every user of vhost_task_create(): the vhost workers and KVM's NX huge page recovery thread. Tested in a VM with a version of tools/virtio/vhost_net_test that puts each RX buffer on a new page, so the vhost worker faults in, and charges, 256M while its cgroup has memory.high=64M. Before, all 285 calls to __mem_cgroup_handle_over_high() came from try_charge_memcg(), inside handle_rx() with vq->mutex held. After, all 589 came from vhost_task_fn(). memory.peak stayed at 64M, and the run took about the same time (0.66s before, 0.67s after). A lockdep kernel showed no warnings. Signed-off-by: Shakeel Butt --- kernel/vhost_task.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/vhost_task.c b/kernel/vhost_task.c index 3717885a5992..f0ab21aa2a1c 100644 --- a/kernel/vhost_task.c +++ b/kernel/vhost_task.c @@ -7,6 +7,7 @@ #include #include #include +#include enum vhost_task_flags { VHOST_TASK_FLAGS_STOP, @@ -38,6 +39,14 @@ static int vhost_task_fn(void *data) break; } + /* + * A vhost task never returns to userspace. Do the work that + * would run on the way back, like memory.high reclaim, here + * between work items, while no locks are held. + */ + if (test_thread_flag(TIF_NOTIFY_RESUME)) + resume_user_mode_work(NULL); + /* mb paired w/ vhost_task_stop */ set_current_state(TASK_INTERRUPTIBLE); -- 2.53.0-Meta