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

[Uladzislau Rezki]

On Wed, Sep 09, 2026 at 09:08:50AM +0800, Hillf Danton wrote:
> On Tue, 8 Sep 2026 16:21:20 +0200 "Uladzislau Rezki (Sony)" wrote:
> >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.
> >
> The difference your patch makes was checked without prio cared.
> 
> >> 
> >> 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;
> 
> Though in general a long running workqueue work is a wart, exceptions exist when
> mm is tight. Just like kswapd that becomes a cpu hog, it is the right thing to do
> for drain_vmap_area_work to take more than 20ms.
> 
> >- 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
> >
> Nope as UNBOUND has nothing to do with cutting the micro seconds the
> drain_vmap_area_work could take.
>
This patch does not use queue_work_on() semantic thus i do not want to
queue all helpers on current CPU. Instead scheduler does balancing and
that is it.

Or you prefer to tight all helpers on local CPUs? What is you concern?

--
Uladzislau Rezki