From: "yanjun.zhu" <yanjun.zhu@linux.dev>
To: Marco Crivellari <marco.crivellari@suse.com>,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org
Cc: Tejun Heo <tj@kernel.org>, Lai Jiangshan <jiangshanlai@gmail.com>,
Frederic Weisbecker <frederic@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Michal Hocko <mhocko@suse.com>, Zhu Yanjun <zyjzyj2000@gmail.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>
Subject: Re: [PATCH] RDMA/rxe: Replace use of system_unbound_wq with system_dfl_wq
Date: Fri, 13 Mar 2026 10:49:50 -0700 [thread overview]
Message-ID: <66bc6576-dda0-4ba9-bd66-f8514e3dda09@linux.dev> (raw)
In-Reply-To: <20260313154023.298325-1-marco.crivellari@suse.com>
On 3/13/26 8:40 AM, Marco Crivellari wrote:
> This patch continues the effort to refactor workqueue APIs, which has begun
> with the changes introducing new workqueues and a new alloc_workqueue flag:
>
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
>
> The point of the refactoring is to eventually alter the default behavior of
> workqueues to become unbound by default so that their workload placement is
> optimized by the scheduler.
>
> Before that to happen, workqueue users must be converted to the better named
> new workqueues with no intended behaviour changes:
>
> system_wq -> system_percpu_wq
> system_unbound_wq -> system_dfl_wq
>
> This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
> removed in the future.
>
> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
This patch is part of a broader effort to clarify workqueue semantics.
As discussed in the recent thread at
https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/], the
move towards system_dfl_wq is not just a renaming exercise; it's about
ensuring work items correctly respect the system's housekeeping CPUMASK.
To RXE, it is a software-defined RDMA transport. RXE does not have
strict hardware-to-CPU affinity requirements. Specifically for the ODP
prefetch path modified here:
1. Prefetching doesn't rely on being executed on the local CPU where the
advise_mr was called.
2. The locality benefits of per-cpu execution are negligible compared to
the importance of system-wide jitter reduction, especially in NOHZ_FULL
environments.
3. By using system_dfl_wq, we allow the scheduler to offload prefetch
tasks from isolated CPUs to housekeeping CPUs, which is a desirable
behavior for real-time users.
The patch is safe, logically sound, and aligns with the current
kernel-wide modernization of workqueue placement.
I have made tests with this commit. It can work well in functionality.
I am fine with this.
Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
Zhu Yanjun
> ---
> drivers/infiniband/sw/rxe/rxe_odp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_odp.c b/drivers/infiniband/sw/rxe/rxe_odp.c
> index bc11b1ec59ac..d440c8cbaea5 100644
> --- a/drivers/infiniband/sw/rxe/rxe_odp.c
> +++ b/drivers/infiniband/sw/rxe/rxe_odp.c
> @@ -545,7 +545,7 @@ static int rxe_ib_advise_mr_prefetch(struct ib_pd *ibpd,
> work->frags[i].mr = mr;
> }
>
> - queue_work(system_unbound_wq, &work->work);
> + queue_work(system_dfl_wq, &work->work);
>
> return 0;
>
next prev parent reply other threads:[~2026-03-13 17:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 15:40 [PATCH] RDMA/rxe: Replace use of system_unbound_wq with system_dfl_wq Marco Crivellari
2026-03-13 17:49 ` yanjun.zhu [this message]
2026-03-16 20:13 ` Leon Romanovsky
2026-03-17 14:32 ` Marco Crivellari
2026-03-17 16:24 ` Leon Romanovsky
2026-03-18 8:34 ` Marco Crivellari
2026-03-18 12:20 ` Marco Crivellari
2026-03-18 14:47 ` Zhu Yanjun
2026-03-18 15:02 ` Leon Romanovsky
2026-03-18 15:08 ` Marco Crivellari
2026-03-17 14:38 ` Zhu Yanjun
2026-03-17 17:24 ` Yanjun.Zhu
2026-03-17 19:03 ` Leon Romanovsky
2026-03-17 19:31 ` Yanjun.Zhu
2026-03-17 20:15 ` Yanjun.Zhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=66bc6576-dda0-4ba9-bd66-f8514e3dda09@linux.dev \
--to=yanjun.zhu@linux.dev \
--cc=bigeasy@linutronix.de \
--cc=frederic@kernel.org \
--cc=jgg@ziepe.ca \
--cc=jiangshanlai@gmail.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=marco.crivellari@suse.com \
--cc=mhocko@suse.com \
--cc=tj@kernel.org \
--cc=zyjzyj2000@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.