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

[Hillf Danton]

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.