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

[Hillf Danton]

On Mon, 14 Sep 2026 18:56:26 +0200 "Uladzislau Rezki (Sony)" wrote:
> 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.
> 
[Fair queue in the Eric Dumazet accent]

+static bool
+schedule_drain_vmap_work(struct workqueue_struct *wq,
+		struct work_struct *work)
+{
+	if (wq)
+		return queue_work(wq, work);
+
+	return false;
+}
+

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/workqueue.h#n697

static inline bool queue_work(struct workqueue_struct *wq,
			      struct work_struct *work)
{
	return queue_work_on(WORK_CPU_UNBOUND, wq, work);
}

queue_work_on
  __queue_work
	if (req_cpu == WORK_CPU_UNBOUND) {
		if (wq->flags & WQ_UNBOUND)
			cpu = wq_select_unbound_cpu(raw_smp_processor_id());
		else
			cpu = raw_smp_processor_id();
	}
/*
 * When queueing an unbound work item to a wq, prefer local CPU if allowed
 * by wq_unbound_cpumask.  Otherwise, round robin among the allowed ones to
 * avoid perturbing sensitive tasks.
 */
static int wq_select_unbound_cpu(int cpu)
{
 	pr_warn_once("workqueue: round-robin CPU selection forced, expect performance impact\n");
}

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

Who blamed kswapd when it became a cpu hog, given it behaves the same way as
a UNBOUND workqueue worker, regarding cpu affinity? Given kswapd is acceptable,
why is vmap work blamed? Unfair.