Re: [PATCH v2] mm/vmalloc: Use dedicated unbound workqueue for vmap purge/drain

[Andrew Morton]

On Mon, 30 Mar 2026 19:58:24 +0200 "Uladzislau Rezki (Sony)" <urezki@xxxxxxxxx> 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 <lirongqing@xxxxxxxxx>
> Link: https://lore.kernel.org/all/20260319074307.2325-1-lirongqing@xxxxxxxxx/
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx>

We don't want to be scaring our users with kernel warnings.  Do you
think a Fixes: or cc:stable are justified?

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.