Re: [PATCH RESEND] mm/vmalloc: Use dedicated unbound workqueues for vmap drain

[Uladzislau Rezki <urezki@gmail.com>]

On Sun, Sep 06, 2026 at 11:50:24AM +0800, Hillf Danton wrote:
> On Sat, 5 Sep 2026 17:27:17 +0200 "Uladzislau Rezki (Sony)" wrote:
> > drain_vmap_area_work() function can take >10ms to complete
> > when there are many accumulated vmap areas in a system with
> > high CPU count, causing workqueue watchdog warnings when run
> > via schedule_work():
> > 
> >   workqueue: drain_vmap_area_work hogged CPU for >10000us
> > 
> > Move the top-level drain work to a dedicated WQ_UNBOUND
> > workqueue so the scheduler can run this background work
> > on any available CPU, improving responsiveness. Use the
> > WQ_MEM_RECLAIM to ensure forward progress under memory
> > pressure.
> >
> If the dedicated worker will run for 4ms on CPU2 before the tick irq kicks it
> off cpu, the system event worker on CPU2 has to wait at least for 4ms to handle
> 200 events for example in 1ms, the net effect is the same as the current scenario
> where 200 events wait for the drain_vmap_area_work to complete on CPU1.
>
It is scheduling decision. We do not want to tune any prio here.

> 
> Different workers does not help to dramatically decrement the micro seconds
> the drain_vmap_area_work takes.
The problem of current approach consists from at least two problems:

- doing progress under memory pressure;
- do not schedule all workers on current CPU and let schedule to find
  the most attractive CPU from its point of view. For example: less busy
  RQ, less energy consuming CPU and so on

--
Uladzislau Rezki