[PATCH] mm/vmalloc: use unbound workqueue for vmap area draining

[lirongqing <lirongqing@baidu.com>]

From: Li RongQing <lirongqing@baidu.com>

The workqueue watchdog currently reports that drain_vmap_area_work
hogs the CPU for more than 10ms. This typically happens during heavy
memory pressure or high-frequency vmap/vunmap operations where the lazy
drain list grows large.

[ 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
[ 3225.388966] workqueue: drain_vmap_area_work hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND

Since vmap area draining is a background housekeeping task that does
not require strict CPU affinity or cache locality, it is a prime
candidate for an unbound workqueue.

Switching from schedule_work() to queue_work(system_unbound_wq, ...)
allows the scheduler to offload the draining process to any available
CPU core. This prevents stalling the current CPU and resolves the
"consider switching to WQ_UNBOUND" warning.

Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 61caa55..5f2218a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2471,7 +2471,7 @@ static void free_vmap_area_noflush(struct vmap_area *va)
 
 	/* After this point, we may free va at any time */
 	if (unlikely(nr_lazy > nr_lazy_max))
-		schedule_work(&drain_vmap_work);
+		queue_work(system_unbound_wq, &drain_vmap_work);
 }
 
 /*
-- 
2.9.4