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 BC93037AA9E for ; Tue, 31 Mar 2026 09:35:28 +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=1774949730; cv=none; b=FuCnfCFAz1FRUk93e/07aZEvCIFuXJlMonaMPloL3CdApPEmvD7lHeabr68iHcZQQAeYP7iRS0/Syl+yWF8z1HWmAlk6g9q5vd5TosHU2Y4/T+MpsHdMSxhBPmHavjAGr5gcdeBYkOBiKAPfWztIgyE2UGTwjyDKOWe/p8xjS+k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774949730; c=relaxed/simple; bh=nD0AAEY2frPvobzca5gkDkVPdpJc0TLn2RujcSujGIU=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CSMpjV2GP4Au8h3X1oJT9iwVp4lGVGMR4+tlhBp8NKOkAr+6tSuYPYe6Cc0udWaV9Q4KOfEhkBf6te3bR+Ct+EsA8QisyM/lFee4mbtLFX5FLjZkKKJVi5wJN0iq2Gv/i5o5PSi7ISJvBisD3SynpOiCKEgzg9vFXJpNjDIfbZA= 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=E/798Jrz; 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="E/798Jrz" Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-5a2a75393e2so4011214e87.2 for ; Tue, 31 Mar 2026 02:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774949727; x=1775554527; 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=Lid4xA2I5RpvLuwKb/5kSWHVsAUfi8ob6hCwRrdpHiE=; b=E/798JrzPqo1ucFN66HM7gnHiwXYocwSlxtcDZWYSp45Eb8mdkQDFtkR+VarWT15tQ HhBqqGNOpBQMmnHUsqcWnP1/B57utNLl58ZmebWfZFY5BA0v7Gl7T3C1QmiVwo0JRXp2 nQC9/JPMxrPGCiHAxcHJ/ur5HJUNFWQG/0yqxl7EqEKvFzJGn+2iWImGTBqIAncsn8mv llKqz86891f1HFQUU/N+0XRt+P5y6Ee+TJei1g/caik+xGaaSq99A0kX6BWvKX85IAjm JVKv6I9KNyv2Aeum0M6kWlTCkjYq4ud3m6k9n/s3QcGeo6T5beGRCZzOfDOMk/PdMUzC I1iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774949727; x=1775554527; 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=Lid4xA2I5RpvLuwKb/5kSWHVsAUfi8ob6hCwRrdpHiE=; b=OL4gav60ZE9gDhg+zROXHQGSwTOdyXPk720ciRlKDq0WGsbNZ4O8U1goUscCdTB6AX u/59imkMGWcuopLK/zP5LB62Ki4DjnHX1L9S/dSXrJ+utXuZ619fxa4YMAjvfM3Ny1Gv NaINtKJCKPcf3j39fa8XN/++S5H8Jkb7Tyz6tE/KQch9qKVXJBSKWsU4AamKnYa/5Qt1 NsYznfqscBHj85a56JW+EvKkwaTFgVqIuzJj1DkW1XC6w/cvAwXvCvNlkAqg6NVfo5Qh YnZYtdD0+ac3I38Ae1o0c0ZassWp7adYofVFCL5vm2QAO6BgEQznEp8OrLVq1U8ivN/H 3ekg== X-Forwarded-Encrypted: i=1; AJvYcCU5gXUt405y095MDFB+pDhKoPCfTWml0C4L14ARIe66B0GzDlQQFGW+jd8FXcU9AN774/UjAY2xLMlXhrI=@vger.kernel.org X-Gm-Message-State: AOJu0YzInWPZENhW9WuZpUg3du9Oyn3mTK3INIlpTbU+wy6vm5tyMeFu SEGPfKiUYys2hcKU3k2iLhZcA+13WQKRQ1maoCZa8iZCmVvkAToyoxDoC/IZBfSE X-Gm-Gg: ATEYQzzYNxZLd76fcawfMRdTMG1FHABV/FkHmjR72xWRJc49XD/9O+yz6438YstdLIt J+hyH2grsvbR1g9H4vQczyhvhmsjtEpXgOlL/XVrEqWkOGxO5I8kvHP8Vqvhx7drEcsqa/6OU5G A/zbtOPyAGXfRL+5Mfn8uUhDS6o3JpIK7olYzbeHZco2BcEgTmtMjEaGX1CkkRK7uGZ39RPXgXQ 6mqKaJL1we8by57JYbgTzTkR8NfkeVSFLomSRJrYf0rWWiyegw+SZqQrZFQsbXSGEJ2IDFLugrz /ScCLqtqkPQn5EiItTllmCdrx43lBd3azIWb/5YnEugoRU0xJ6IyjP4ImFCiK7xmKGHDpB64E6h 19thdBOiXob10R6f2dVT17D5gEF9yEgyjq+ybOYL8nuiNEYylDIraiR4DXpCjYUH2EWfDHM5T45 E= X-Received: by 2002:a05:6512:3053:b0:5a2:b86c:f2d6 with SMTP id 2adb3069b0e04-5a2b86cf38emr1680912e87.11.1774949726405; Tue, 31 Mar 2026 02:35:26 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a2b1403c4esm2257320e87.26.2026.03.31.02.35.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2026 02:35:26 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 31 Mar 2026 11:35:24 +0200 To: Andrew Morton Cc: "Uladzislau Rezki (Sony)" , 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> <20260330115618.62fb0d6bdf89cedd453035d0@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: <20260330115618.62fb0d6bdf89cedd453035d0@linux-foundation.org> On Mon, Mar 30, 2026 at 11:56:18AM -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, both. > > > Cc: lirongqing > > Link: https://lore.kernel.org/all/20260319074307.2325-1-lirongqing@baidu.com/ > > Signed-off-by: Uladzislau Rezki (Sony) > > We don't want to be scaring our users with kernel warnings. Do you > think a Fixes: or cc:stable are justified? > Probably we can CC stable. > And I wonder if that workqueue warning should be WARN_ON_ONCE. That > would mean that other, later call sites wouldn't get the report, but > we'll still get to hear about those callsites from someone else. > I can switch to ONCE version. Below code: static int __init vmalloc_init_workqueue(void) { struct workqueue_struct *wq; wq = alloc_workqueue("vmap_drain", WQ_UNBOUND | WQ_MEM_RECLAIM, 0); WARN_ON(wq == NULL); WRITE_ONCE(drain_vmap_wq, wq); return 0; } early_initcall(vmalloc_init_workqueue); implies to be called/initialized only once. -- Uladzislau Rezki