Re: [PATCH rdma-next] RDMA/addr: create addr_wq with WQ_MEM_RECLAIM flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 31, 2019 at 01:56:15PM -0700, Parav Pandit wrote:
> 
> 
> > From: linux-rdma-owner@xxxxxxxxxxxxxxx <linux-rdma-
> > owner@xxxxxxxxxxxxxxx> On Behalf Of Steve Wise
> > Sent: Thursday, January 31, 2019 1:31 PM
> > To: dledford@xxxxxxxxxx; Jason Gunthorpe <jgg@xxxxxxxxxxxx>
> > Cc: linux-rdma@xxxxxxxxxxxxxxx
> > Subject: [PATCH rdma-next] RDMA/addr: create addr_wq with
> > WQ_MEM_RECLAIM flag
> > 
> > While running NVMe/oF wire unplug tests, we hit this warning in
> > kernel/workqueue.c:check_flush_dependency():
> > 
> > WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
> > 		      (WQ_MEM_RECLAIM | __WQ_LEGACY)) ==
> > WQ_MEM_RECLAIM),
> > 	  "workqueue: WQ_MEM_RECLAIM %s:%pf is flushing
> > !WQ_MEM_RECLAIM %s:%pf",
> > 	  worker->current_pwq->wq->name, worker->current_func,
> > 	  target_wq->name, target_func);
> > 
> > Which I think means we're flushing a workq that doesn't have
> > WQ_MEM_RECLAIM set, from workqueue context that does have it set.
> > 
> > Looking at rdma_addr_cancel() which is doing the flushing, it flushes the
> > addr_wq which doesn't have MEM_RECLAIM set.  Yet rdma_addr_cancel() is
> > being called by the nvme host connection timeout/reconnect workqueue
> > thread that does have WQ_MEM_RECLAIM set.
> > 
> > So set WQ_MEM_RECLAIM on the addr_req workqueue.
> >
> 
> Please add below [1] fixes by tag.
> I removed this flag based on commit [2] of Sagi and discussion[3].
> Which I think [2] and [3] are incorrect.
> 
> Memory reclaim path could have been triggered by processes or kernel
> and I think it is ok to allocate a memory in a work item trigger as
> part of reclaim path or otherwise.  Memory allocation in a wq has
> nothing to do with memory reclaim. I wish if Tejun or Christoph
> confirm this is right or correct our understanding.

Considering the only thing WQ_MEM_RECLAIM does is to pre-allocate a
execution progress to guarentee forward progress if the system is
unable to succed in memory allocations..

It seems a bit goofy to say that it is OK to then block on memory
allocations inside that precious execution context..

I also would like to understand what the rules should be for this flag
before applying this patch??

> Based these past discussions, it appears to me that WQ_MEM_RECLAIM
> limitation and its use is not clear.

I've always thought it was designed to guarentee forward progress if
memory cannot be allocated.

Jason




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux