quoted

quoted

quoted

Does anyone else know?

Consider that the ib_core can be used to back storage. Ie consider a
situation where iSER/NFS/SRP needs to reconnect to respond to kernel
paging/reclaim.

On the surface it seems reasonable to me that these are on a reclaim
path?

I'm pretty sure that ULP connect will trigger memory allocations, which
will fail under memory pressure... Maybe I'm missing something.

quoted

hmm.  That seems reasonable.  Then I would think the nvme_rdma would also need
to be using a reclaim workqueue.

Sagi, Do you think I should add a private workqueue with WQ_MEM_RECLAIM to
nvme_rdma vs using the system_wq?  nvme/target probably needs one also...

I'm not sure, being unable to flush system workqueue from CM context is
somewhat limiting... We could use a private workqueue for nvmet
teardowns but I'm not sure we want to do that.

The workqueue which frees the memory and doesn't allocate memory during execution
is supposed to be marked as WQ_MEM_RECLAIM. This flag will cause to priority increase
for such workqueue during low memory conditions.

Which to my understanding means that CM workqueue should not use it as
on each CM connect, by definition the ULP allocates memory (qp, cq etc).
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html