From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F6E23603FB for ; Wed, 18 Mar 2026 18:10:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773857409; cv=none; b=qsUjGI3MzwyUu9HjzTzI4CYS5bkpwb9fCpl0eIwBEgtPqyUyWtl4tL2W0xWJmrvq49Q7zBgMsO6YmfYDRV5QDH3MpomLWb3U2Yrys1aUWCxd0EyITEEPe41Ts6UdG2AFvKXJ7OVYTAc3eA9r8tuMdJPzZsF7dAy05ujTr8lYzy4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773857409; c=relaxed/simple; bh=X0qYY8laPBOQhTioEGSZ8BFult+iVbgPGjJ+9hRcKqU=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QX8NSN0q1yjF9kLK/pxualoz0q00uqQ7mltt5+f/4mopLjI73zyYWERpW3l6adDTolBNvWC4vIRHzA2XyA4FuZ0OR778JprzAd0v88KXRu2w5p1UYqqB6bRoSiFsizDMSZeZK4WwiLUEIxMQohupkoKmlTYOnz7YMMq6+vcAczE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TC13dXun; arc=none smtp.client-ip=209.85.208.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TC13dXun" Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-38bd15d82bdso1211641fa.2 for ; Wed, 18 Mar 2026 11:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773857406; x=1774462206; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=LqCwTUD6zrFGHKkKX0YkpZNWhhJCFlSqR1azNDH71o4=; b=TC13dXunpqfJR301VV1eBMeujVnHMVC6nFXUjrtytIFGvTcsvLb6YG3B/4iGSEQx19 aah+KbEag0PsPk5gE22WZEssU+SCRtxwjzrmHv+ltbJnHzxQ1obNNIxoUGgO9XhUv/92 lQo8jaWGjcc9b8QDHjrmg40nS0zG8LZkcZVfeJmMc2fNpGMzqk8V5uA6Fvcg1FSNoFgi +Qkmo4ix0kLQR/7xiLMBqSg7BAJqYM31IMiTt+AM3u5IoNCwQJcMxc2fBiB39ReQKM7+ flvJYYVV3xKvJYhxMSlUdColkUJFPY5BpAl1mQQlsHdAxVLBe7cERrTrXOz+rlotvGue PTnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773857406; x=1774462206; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LqCwTUD6zrFGHKkKX0YkpZNWhhJCFlSqR1azNDH71o4=; b=gPpkP0b88i5tz1m+3wOgC6ixyiqsPhInNJhhD8G2M2ejopVLvJJBug5IvEV6LiH9Mg mN1doqxPF1+IBUo4oTzmIUNXHwOqeIv1VgNiUOV+pYO3c2uApgCisjHj27fV/pZA15Oe sjS6/Wj2TGIJoWvR1/aoBlQYREOzQvkrYP+3nwEJUN46//2fGkrh4cETVUJiwkHIwjiK 07C38xlReQFa+O1E6CMlGIW2No+23TueOXwflEbMmcAW/6F0n112/NrRysK9CaUCmoxs qaq+I5ALLp8pwusCCPuZWc86bFMpbu3kZjbU/njOrWn6WN7u/K+A9nU+nL2MJvnw9YIp 0I3w== X-Forwarded-Encrypted: i=1; AJvYcCX6T6t0yp96BlSfWMhMfeljx7VpuQ/78vtwiUU9VX9I8jjjItihLFn/L8XRumwGhNKbJdos/ENBcXHq/DI=@vger.kernel.org X-Gm-Message-State: AOJu0Yxznvg+JBpHN3OVPcNr7/j3VWlWGLhmxDh5YvfLlWW99IswCGNM VcVdTypHOCK4YmIr29EkNvt5atFoFIRnbW2x8qBg1V5WWJZMDJEMUgAY X-Gm-Gg: ATEYQzxy+gIa2aRurqS7vBuuMfG1I1STeVv41PUG6bl2Wy9Eqa3snavYvrRztNjWDoQ y/rZEuD8aXI2zYsNMXD+7+h6qy1UuIXEEJXpaWCUEiMZbPZGcNktbrntw1zEs4zQ40GQaxkmj2c 7XfJt63y6utt4QVR62ApydBzDTEZPfP9WmkmWamQnvWH2j26PX/AB7S9YhtjYz0s49amTglpzp3 jIV9wDN8OO0KxNZH8GHBa7jocRNyF+IhYFVaOwgwkZ6TR1WLOSURFVaIYh6T0yRMPUO1/uds5d/ IydbeVFh3Ghydhrw1vGzC0beVzm84nVw/pFNtjVT7QT2Osy5biz6VVM5GVjgK82swma/knvIrY9 RzIvF2bCJat2VaXpydPlR5RsFpKj3YoNgIiPba/JXdLbhKZS8QRXB5Bg7fZRPx2ol X-Received: by 2002:a05:651c:32f:b0:38a:4aee:423d with SMTP id 38308e7fff4ca-38bd588d042mr14940351fa.32.1773857406052; Wed, 18 Mar 2026 11:10:06 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-38bd54ba2afsm7229611fa.28.2026.03.18.11.10.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2026 11:10:05 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 18 Mar 2026 19:10:03 +0100 To: lirongqing Cc: Andrew Morton , Uladzislau Rezki , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/vmalloc: use unbound workqueue for vmap area draining Message-ID: References: <20260318073630.2325-1-lirongqing@baidu.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260318073630.2325-1-lirongqing@baidu.com> On Wed, Mar 18, 2026 at 03:36:30AM -0400, lirongqing wrote: > 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 times, consider switching to WQ_UNBOUND > [ 2192.823225] workqueue: drain_vmap_area_work hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND > [ 3225.388966] workqueue: drain_vmap_area_work hogged CPU for >10000us 7 times, 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) > > /* 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); > } > > /* > -- > 2.9.4 > We free memory here. Therefore it is time to switch to our own workqueue with WQ_MEM_RECLAIM | WQ_UNBOUND flags. -- Uladzislau Rezki