All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Baoquan He <bhe@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	lirongqing <lirongqing@baidu.com>
Subject: Re: [PATCH v2] mm/vmalloc: Use dedicated unbound workqueue for vmap purge/drain
Date: Tue, 31 Mar 2026 16:11:40 +0200	[thread overview]
Message-ID: <acvWHBzPc82kPEdM@milan> (raw)
In-Reply-To: <acuWOtKmPTzrYEEG@milan>

On Tue, Mar 31, 2026 at 11:39:06AM +0200, Uladzislau Rezki wrote:
> On Mon, Mar 30, 2026 at 12:16:25PM -0700, Andrew Morton wrote:
> > On Mon, 30 Mar 2026 19:58:24 +0200 "Uladzislau Rezki (Sony)" <urezki@gmail.com> wrote:
> > 
> > > The drain_vmap_area_work() function can take >10ms to complete
> > > when there are many accumulated vmap areas in a system with a
> > > high CPU count, causing workqueue watchdog warnings when run
> > > via schedule_work():
> > > 
> > > [ 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
> > > 
> > > Switch to a dedicated WQ_UNBOUND workqueue to allow the scheduler to
> > > run this background task on any available CPU, improving responsiveness.
> > > Use WQ_MEM_RECLAIM to ensure forward progress under memory pressure.
> > > 
> > > If queuing work to the dedicated workqueue is not possible(during
> > > early boot), fall back to processing locally to avoid losing progress.
> > > 
> > > Also simplify purge helper scheduling by removing cpumask-based
> > > iteration in favour to iterating directly over vmap nodes with
> > > pending work.
> > 
> > Thanks.  AI review flagged a couple of possible issues.  Do they look
> > real to you?
> > 	https://sashiko.dev/#/patchset/20260330175824.2777270-1-urezki@gmail.com
> >
> I think the problem about itself locking if running by rescue thread is
> a valid concern. I will address this. I think the easiest is to use two
> UNBOUND queues one for master/main thread and second for helpers which
> reclaim if there are too many objects so the help is needed.
> 
> I will work on v3.
> 
> Thank you for review!
> 
> --
> Uladzislau Rezki
>
I will fix the AI concern by maintaining two queues. One is parent
second one is for child helpers. That way both will not block each
other and both have a rescue context to move progress forward:

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 6bc2523bf75b..2c1ed76cffe8 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1068,6 +1068,7 @@ static void reclaim_and_purge_vmap_areas(void);
 static BLOCKING_NOTIFIER_HEAD(vmap_notify_list);
 static void drain_vmap_area_work(struct work_struct *work);
 static DECLARE_WORK(drain_vmap_work, drain_vmap_area_work);
+static struct workqueue_struct *drain_vmap_helpers_wq;
 static struct workqueue_struct *drain_vmap_wq;
 
 static __cacheline_aligned_in_smp atomic_long_t nr_vmalloc_pages;
@@ -2338,10 +2339,9 @@ static void purge_vmap_node(struct work_struct *work)
 }
 
 static bool
-schedule_drain_vmap_work(struct work_struct *work)
+schedule_drain_vmap_work(struct workqueue_struct *wq,
+		struct work_struct *work)
 {
-	struct workqueue_struct *wq = READ_ONCE(drain_vmap_wq);
-
 	if (wq) {
 		queue_work(wq, work);
 		return true;
@@ -2400,7 +2400,8 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end,
 
 			if (nr_purge_helpers > 0) {
 				INIT_WORK(&vn->purge_work, purge_vmap_node);
-				vn->work_queued = schedule_drain_vmap_work(&vn->purge_work);
+				vn->work_queued = schedule_drain_vmap_work(
+					READ_ONCE(drain_vmap_helpers_wq), &vn->purge_work);
 
 				if (vn->work_queued) {
 					nr_purge_helpers--;
@@ -2479,7 +2480,8 @@ 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_drain_vmap_work(&drain_vmap_work);
+		schedule_drain_vmap_work(READ_ONCE(drain_vmap_wq),
+			&drain_vmap_work);
 }
 
 /*
@@ -5494,11 +5496,16 @@ void __init vmalloc_init(void)
 
 static int __init vmalloc_init_workqueue(void)
 {
-	struct workqueue_struct *wq;
+	struct workqueue_struct *drain_wq, *helpers_wq;
+	unsigned int flags = WQ_UNBOUND | WQ_MEM_RECLAIM;
+
+	drain_wq = alloc_workqueue("vmap_drain", flags, 0);
+	WARN_ON_ONCE(drain_wq == NULL);
+	WRITE_ONCE(drain_vmap_wq, drain_wq);
 
-	wq = alloc_workqueue("vmap_drain", WQ_UNBOUND | WQ_MEM_RECLAIM, 0);
-	WARN_ON(wq == NULL);
-	WRITE_ONCE(drain_vmap_wq, wq);
+	helpers_wq = alloc_workqueue("vmap_drain_helpers", flags, 0);
+	WARN_ON_ONCE(helpers_wq == NULL);
+	WRITE_ONCE(drain_vmap_helpers_wq, helpers_wq);
 
 	return 0;
 }


if no complains, i will send out v3 soon.

--
Uladzislau Rezki


  reply	other threads:[~2026-03-31 14:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 17:58 [PATCH v2] mm/vmalloc: Use dedicated unbound workqueue for vmap purge/drain Uladzislau Rezki (Sony)
2026-03-30 18:56 ` Andrew Morton
2026-03-31  9:35   ` Uladzislau Rezki
2026-03-30 19:16 ` Andrew Morton
2026-03-31  9:39   ` Uladzislau Rezki
2026-03-31 14:11     ` Uladzislau Rezki [this message]
2026-03-31  7:42 ` [syzbot ci] " syzbot ci

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=acvWHBzPc82kPEdM@milan \
    --to=urezki@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lirongqing@baidu.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.