From: "Yanjun.Zhu" <yanjun.zhu@linux.dev>
To: Leon Romanovsky <leon@kernel.org>, Zhu Yanjun <yanjun.zhu@linux.dev>
Cc: zyjzyj2000@gmail.com, jgg@ziepe.ca, linux-rdma@vger.kernel.org
Subject: Re: [PATCH 1/1] RDMA/rxe: Use a dedicated and robust workqueue for RXE tasks
Date: Wed, 18 Mar 2026 09:10:51 -0700 [thread overview]
Message-ID: <d46334d3-2344-403f-8376-52afa7089e48@linux.dev> (raw)
In-Reply-To: <20260318154133.GF352386@unreal>
On 3/18/26 8:41 AM, Leon Romanovsky wrote:
> On Wed, Mar 18, 2026 at 08:34:42AM -0700, Zhu Yanjun wrote:
>> 在 2026/3/18 7:53, Leon Romanovsky 写道:
>>> On Wed, Mar 18, 2026 at 03:57:39AM +0100, Zhu Yanjun wrote:
>>>> Currently, the RXE driver uses the system-wide 'system_unbound_wq' for
>>>> auxiliary tasks like ODP prefetching. This can lead to interference
>>>> from other system services and lacks guaranteed forward progress
>>>> under memory pressure.
>>>>
>>>> Currently make all the tasks queue into the driver-specific 'rxe_wq'.
>>>>
>>>> Suggested-by: Leon Romanovsky <leon@kernel.org>
>>>> Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
>>>> ---
>>>> drivers/infiniband/sw/rxe/rxe_odp.c | 2 +-
>>>> drivers/infiniband/sw/rxe/rxe_task.c | 10 +++++++++-
>>>> drivers/infiniband/sw/rxe/rxe_task.h | 1 +
>>>> 3 files changed, 11 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/infiniband/sw/rxe/rxe_odp.c b/drivers/infiniband/sw/rxe/rxe_odp.c
>>>> index bc11b1ec59ac..98092dcc1870 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);
>>>> + rxe_queue_work(&work->work);
>>>> return 0;
>>>> diff --git a/drivers/infiniband/sw/rxe/rxe_task.c b/drivers/infiniband/sw/rxe/rxe_task.c
>>>> index f522820b950c..4385137eb4d7 100644
>>>> --- a/drivers/infiniband/sw/rxe/rxe_task.c
>>>> +++ b/drivers/infiniband/sw/rxe/rxe_task.c
>>>> @@ -10,7 +10,8 @@ static struct workqueue_struct *rxe_wq;
>>>> int rxe_alloc_wq(void)
>>>> {
>>>> - rxe_wq = alloc_workqueue("rxe_wq", WQ_UNBOUND, WQ_MAX_ACTIVE);
>>>> + rxe_wq = alloc_workqueue("rxe_wq", WQ_UNBOUND | WQ_MEM_RECLAIM,
>>> Why did you add WQ_MEM_RECLAIM flag? rxe_ib_advise_mr_prefetch() doesn't
>>> perform any memory reclaim.
>> You are correct that rxe_ib_advise_mr_prefetch() does not directly call
>> memory reclaim functions.
>>
>> However, the WQ_MEM_RECLAIM flag was added to prevent circular dependencies
>> during
>>
>> low-memory conditions.
>>
>> Since rxe handles memory regions that may be part of the storage or network
>> stack,
>>
>> the workqueue must be able to make progress even when the system is under
>> extreme
>>
>> memory pressure. Without this flag, if the kernel attempts to reclaim memory
>> and that
>>
>> reclaim process depends on an RDMA operation being processed by this
>> workqueue,
>>
>> the system could deadlock because the workqueue might be unable to spawn a
>> new
>>
>> worker thread.
>>
>> By setting WQ_MEM_RECLAIM, we ensure that a rescuer thread is pre-allocated,
>>
>> guaranteeing that prefetch and MR-related tasks can complete and allow the
>>
>> memory management subsystem to finish its reclaim cycle.
> Zhu,
>
> Please avoid relying on AI when answering ML-related questions. The
> response you received is broadly correct, but it is incorrect for RXE.
> You should set the WQ_MEM_RECLAIM flag only when the workqueue handlers
OK. Thanks a lot.
Zhu Yanjun
> free memory. RXE does the opposite in rxe_ib_advise_mr_prefetch().
>
> Thanks
>
>>
>> Zhu Yanjun
>>
>>> Thanks
>> --
>> Best Regards,
>> Yanjun.Zhu
>>
>>
prev parent reply other threads:[~2026-03-18 16:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 2:57 [PATCH 1/1] RDMA/rxe: Use a dedicated and robust workqueue for RXE tasks Zhu Yanjun
2026-03-18 14:53 ` Leon Romanovsky
2026-03-18 15:34 ` Zhu Yanjun
2026-03-18 15:41 ` Leon Romanovsky
2026-03-18 16:10 ` Yanjun.Zhu [this message]
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=d46334d3-2344-403f-8376-52afa7089e48@linux.dev \
--to=yanjun.zhu@linux.dev \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox