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

[Hillf Danton]

On Thu, 17 Sep 2026 19:03:47 +0200 "Uladzislau Rezki (Sony)" wrote:
> On Thu, Sep 17, 2026 at 08:07:37AM +0800, Hillf Danton wrote:
> > 
> > Given numa node1 including cpu8-15 without cpu hotplug cared, a bound worker
> > for cpu9 can not migrate to any other cpu, while a unbound worker can run on
> > any cpu of node1, that is all.
> > 
> Right. 
> 
> <snip>
> 	if (list_empty(&pwq->inactive_works) && pwq_tryinc_nr_active(pwq, false)) {
> 		if (list_empty(&pool->worklist))
> 			pool->last_progress_ts = jiffies;
> 
> 		trace_workqueue_activate_work(work);
> 		insert_work(pwq, work, &pool->worklist, work_flags);
> 		kick_pool_pick(pool, &wake_task);
> 	} else {
> 		work_flags |= WORK_STRUCT_INACTIVE;
> 		insert_work(pwq, work, &pwq->inactive_works, work_flags);
> 	}
> 
> out:
> 	raw_spin_unlock(&pool->lock);
> 	if (wake_task)
> 		wake_up_process(wake_task);
> <snip>
> 
> wake_up_process(wake_task) - this guy takes care about task placement.
> For us it is TASK_FAIR thus select_task_rq_fair() decides the fate of
> unbound kworker.
>
At best an idle cpu is selected for the unbound worker, but it may be
preempted the next micro second. Maybe you disagree, eevdf means uncertain.

Even given an idle cpu without preempt, it fails to prevent the vmap
work from becoming a wart, no?