From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (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 1E5DE3E0C75 for ; Tue, 31 Mar 2026 14:11:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774966305; cv=none; b=r4hyRCGLyl3IL/SUlDCX5xqWUZ9Q+W82j8FBprdL8uX9X4G5ZVb25OEFeGDmNs0DGHVRCl/W9TRFsulroyp0qQjiQUHACv0aqlA2dc+TVVYAJnNV1lSlSqkFJqJDo9xRhHi+gOr+D6Syhq9+wAJLrgNIMhG3WNIbFsNsx2m5iJ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774966305; c=relaxed/simple; bh=5rFLwUBtClOICCEiq9OTFPpkc53mTOLRng7dKPWgA4w=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dwR+i1LT8n2I59/el3XhjsVz56Epts/3WnPhn+ydpXiDtAG+yN1UDEXMixRu3mXsK5sZp4ogOKH8yU0RUCNk4vOJt/n6WhOdcH+Ib+jSrjdwI/U6qexzVuw6TE/H/ZRxOlBm5L8ih9lQ2bqx8LdXoA4Ma3aGcXSy567KvYWPgH8= 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=ca1FGWBH; arc=none smtp.client-ip=209.85.167.41 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="ca1FGWBH" Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-5a27b5ad832so6605834e87.2 for ; Tue, 31 Mar 2026 07:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774966302; x=1775571102; 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=uEOp0RWGebAq1pKpMH/DnvyOx31FKeMcpUjas+GFEbY=; b=ca1FGWBHnrKBbJuhpkh4reCxG5MceurxFZUGvpZ6XAs1Nkxk3Xfpm6VBn0ryiWa6x8 kTLAayxmUJnTbH4fTh79/GJeE8Scj4PXriSy8acpajcktwekPj1XUydWHNzqZB0Ac7oP YoNoKrAE9Y81jOiBy9Ho3WWGAGRIIZ7Y/Chqy2O+Kmqq6uFYJhymOQcd1eVkE8HaQLU6 KHx5XtclCBAmyt82MhwYWitZ35bTUdhT9dcI3w1X8OEumKL9jo/ylIuvn074J0fx+9ML FyEXILla7UL7tHBYXTaBuqAZyPZYdmxEvenUMsXsDT29T8utxg8N8QyUbjxKNnc0nv3J ziuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774966302; x=1775571102; 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=uEOp0RWGebAq1pKpMH/DnvyOx31FKeMcpUjas+GFEbY=; b=Ej+2QZwnEG73Pzry5YJJqrCRfpdvLEpkpcGSKiIftebRgBiddJ/YqUoy/CZuvN3YbW ZCfkqU9S+aZD+vks5n7eIANP8tzkyvittQI5OPGKl0hcpaXWo+iu67kG/rvEcXRsm453 LKWVzAJPfa+r6tvR8/qzRkaPfhBxYNiexvPxjmS5nlSh0pQKU6r51JG8hG+CzdBj3zIn tN1bxH3oAp6Rsb4YUiBQUlYpCQk9YBcJXN70SfrFSnpcOc/mM+e6D7o1z3cOuhrQEnen 7/2YyeGTK3deqQAUZeuksDO0YMJPkCTPj7iFdqaUn5SSZOJyozJzTjzasvqpP6Q3g/b7 W+Tw== X-Forwarded-Encrypted: i=1; AJvYcCUXjF3yKkWVu20/RC8aOGIcnPry1G6uCR8XJhsiPLfQQn1+Ib5cl2UskfhRVmua9L39eEUQN4dRCU1JkbY=@vger.kernel.org X-Gm-Message-State: AOJu0YyW/qhJa50VGHMEAHUfvBAIuYmz4lWQ6e7exQHrB3yRbJIjLT+i mOYuCMeftXGSZbfwMD48kifzifQ4N38U3KFafBMhy9YHtYlp7ORQVFPx X-Gm-Gg: ATEYQzwTsVYCvEtIew2qPEmDnyrcmIXdGOLbGUieQAv1P6cwlTCE3fqf/vi2H+x5S/i hKAEl+pSAoMrUnossoCcfTJ1odbL9W0yk8mmKACfB521iIzLvV7d2hCdJGHvRgstUkqAc6oJgfx qzRgDGPdDti7c32QI/hPRIlZkHMwYnR3/kGP45UQh6A4XQ4QFOPwKi26U0SinT83e/+k+UhwepT jnkPpsgWnB6KVk6ESAQ3fcTj2blQ+cJ2tO8ZIH4pXHWb4+C6oPlfiY+picMIF39saoPN1SMlZIo Nd+WbVjLpQOYoKHMxl2O0MMTus9XSLsaOW7xOAXhugYXkqCOrcxBQLGiZN9xEo6BZ8vbqk1ynQV F0qO6hQsAqlUSutwLKZBS5A9025+MuPIDn/nqnAoSRggZ8v0YJLJR3FM0D+tg+Bs7za7eHPpeiI Q= X-Received: by 2002:a05:6512:695:b0:59e:57d2:75f0 with SMTP id 2adb3069b0e04-5a2ab928655mr5498684e87.32.1774966301894; Tue, 31 Mar 2026 07:11:41 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a2bd66239asm514817e87.51.2026.03.31.07.11.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2026 07:11:41 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 31 Mar 2026 16:11:40 +0200 To: Andrew Morton Cc: Andrew Morton , linux-mm@kvack.org, Baoquan He , LKML , lirongqing Subject: Re: [PATCH v2] mm/vmalloc: Use dedicated unbound workqueue for vmap purge/drain Message-ID: References: <20260330175824.2777270-1-urezki@gmail.com> <20260330121625.c69f46a63c86c9540b823398@linux-foundation.org> 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: 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)" 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