From nobody Mon Apr 6 19:39:21 2026 Received: from outbound.baidu.com (mx14.baidu.com [220.181.3.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5CB9F285404 for ; Wed, 18 Mar 2026 07:41:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.181.3.101 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773819790; cv=none; b=BJtdVNQPyOWcpMFp4G9nuywY39PLuRiNtsSmJVGN3QfRlzEnnupXX9DXTpQA4YyX1a16RCrftBC+1sWZqlBrxYwviLAO6kItcinLYtJyAkuarXho/m6pnjIZSQnFYo0v6xEIZY4J7xWJX6L+YJFBDsm1bQspv+2rKD2wXG/UQbg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773819790; c=relaxed/simple; bh=go6OXN105bxKSCsJhPOtszQp56rK651G7bE1MO5Ob7c=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=SAT8cFJyTB8zNUfKNtF/balxlqrS4gqIqAM+Kvm9zAup9CLB9d6mMdXxC4+759bZQOjPWUU/HBIbtGLeTpPdaM3I/tV4iUTSoLGKsIf8YJVuUZd3v3MSY0dxXzUcKFm0POQMp0Jt3EQTW6yx/Ps53nVpb/bRXTXQvHijF6Hbf6E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=baidu.com; spf=pass smtp.mailfrom=baidu.com; dkim=pass (2048-bit key) header.d=baidu.com header.i=@baidu.com header.b=aJMMUhsZ; arc=none smtp.client-ip=220.181.3.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=baidu.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baidu.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baidu.com header.i=@baidu.com header.b="aJMMUhsZ" X-MD-Sfrom: lirongqing@baidu.com X-MD-SrcIP: 172.31.50.47 From: lirongqing To: Andrew Morton , Uladzislau Rezki , , CC: Li RongQing Subject: [PATCH] mm/vmalloc: use unbound workqueue for vmap area draining Date: Wed, 18 Mar 2026 03:36:30 -0400 Message-ID: <20260318073630.2325-1-lirongqing@baidu.com> X-Mailer: git-send-email 2.17.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: bjkjy-exc13.internal.baidu.com (172.31.51.13) To bjkjy-exc3.internal.baidu.com (172.31.50.47) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baidu.com; s=selector1; t=1773819405; bh=y2YpHlh+WSQL0MG8EwEamlgcCGzhk9KPm0u1wFzft7g=; h=From:To:CC:Subject:Date:Message-ID:Content-Type; b=aJMMUhsZV0dPMeLMoSc3OEcCFITsxjOVWXbsjLO3IJOjkAkcTRCcGDpVUfzGwZ8Kf qUzZaok/FlN58fFclDe0XCD5NJas1KM2cXRbkLPXlMGmL6ktY1k5F5QliAHgbLsFhE d8aUebxRlGdLMK0LhDMIDTcQpccKuLohHOM1X+CorAPA0QGNR0OKhK8UmnFuPEZ+Kg 9XDCwq4GLTqpW/eprIzEn+O5YAlEPtZbaY/5AggBhas3RDmQt8JY+Z/ZlaoO+4iqcq ATNNH0JqiHv9UfG3MBzWYWRmG37Hj7APAattK3YG7vkdBx+CvzqvI18YU1pg+yULET ZzccVof4QPhvQ== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li RongQing The workqueue watchdog currently reports that drain_vmap_area_work hogs the CPU for more than 10ms. This typically happens during heavy memory pressure or high-frequency vmap/vunmap operations where the lazy drain list grows large. [ 2069.796205] workqueue: drain_vmap_area_work hogged CPU for >10000us 4 ti= mes, consider switching to WQ_UNBOUND [ 2192.823225] workqueue: drain_vmap_area_work hogged CPU for >10000us 5 ti= mes, consider switching to WQ_UNBOUND [ 3225.388966] workqueue: drain_vmap_area_work hogged CPU for >10000us 7 ti= mes, consider switching to WQ_UNBOUND Since vmap area draining is a background housekeeping task that does not require strict CPU affinity or cache locality, it is a prime candidate for an unbound workqueue. Switching from schedule_work() to queue_work(system_unbound_wq, ...) allows the scheduler to offload the draining process to any available CPU core. This prevents stalling the current CPU and resolves the "consider switching to WQ_UNBOUND" warning. Signed-off-by: Li RongQing --- mm/vmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 61caa55..5f2218a 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2471,7 +2471,7 @@ static void free_vmap_area_noflush(struct vmap_area *= va) =20 /* After this point, we may free va at any time */ if (unlikely(nr_lazy > nr_lazy_max)) - schedule_work(&drain_vmap_work); + queue_work(system_unbound_wq, &drain_vmap_work); } =20 /* --=20 2.9.4