On Wed, 2019-03-27 at 14:25 -0700, Tejun Heo (tj@xxxxxxxxxx) wrote:
> Hello,
>
> On Wed, Mar 27, 2019 at 04:43:47PM -0300, Jason Gunthorpe wrote:
> > Well, at least I'm not super familiar with the block layer and
> > wouldn't know about this..
>
> Yeah, conceptually it's not complex. Filesytem and IOs are needed to
> reclaim memory because we need to write back dirty pagecache and swap
> pages before reuse them for other purposes. Recursing on oneself
> obviously won't be great, so filesystems need to use GFP_NOFS and
> block layer below that needs to use GFP_NOIO.
>
> It's kinda unfortunate that network devices end up being pushed into
> this dependency chain but we do put them in memory reclaim path w/ nfs
> and block-over-network things, so it is what it is, I suppose.
The discussion is helpful, but we still need to decide on the patch:
Correct me if I'm wrong Tejun, but the key issues are:
All WQ_MEM_RECLAIM work queues are eligible to be run when the machine
is under extreme memory pressure and attempting to reclaim memory. That
means that the workqueue:
1) MUST not perform any GFP_ATOMIC allocations as this could deadlock
2) SHOULD not rely on any GFP_KERNEL allocations as these may fail
3) MUST complete without blocking
4) SHOULD ideally always make some sort of forward progress if at all
possible without needing memory allocations to do so
Mike, does hfi1_do_send() meet these requirements? If not, we should
not be putting WQ_MEM_RECLAIM on it, and instead should find another
solution to the current trace issue.
> > But your explanation is helpful. I will be watching for WQ_MEM_RECLAIM
> > users that are allocating memory in their work functions.
> >
> > Would it be possible to have a lockdep-like debugging under kmalloc
> > similar to check_flush_dependency() that complains if a WQ_MEM_RECLAIM
> > work is doing inappropriate allocations?
> >
> > That would help discourage using it in WQ's it shouldn't be used on.
>
> Yeah, I was wondering whether that'd trigger warning. I don't think
> it does now. I fully agree it'd be great to have.
>
> Thanks.
>
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
