Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

From: Jeff Layton
Date: Thu Mar 17 2016 - 21:32:32 EST


On Thu, 17 Mar 2016 09:45:46 -0700
Tejun Heo <tj@xxxxxxxxxx> wrote:

> Hello,
>
> Years ago, workqueue got reimplemented to use common worker pools
> across different workqueues and a new set of more expressive workqueue
> creation APIs, alloc_*workqueue() were introduced. The old
> create_*workqueue() became simple wrappers around alloc_*workqueue()
> with the most conservative parameters. The plan has always been to
> examine each usage and convert to the new interface with parameters
> actually required for the use case.
>
> One important flag to decide upon is WQ_MEM_RECLAIM, which declares
> that the workqueue may be depended upon during memory reclaim and thus
> must be able to make forward-progress even when further memory can't
> be allocated without reclaiming some. Of the network drivers which
> already use alloc_*workqueue() interface, some specify this flag and
> I'm wondering what the guidelines should be here.
>
> * Are network devices expected to be able to serve as a part of
> storage stack which is depended upon for memory reclamation?
>

I think they should be. Cached NFS pages can consume a lot of memory,
and flushing them generally takes network device access.

> * If so, are all the pieces in place for that to work for all (or at
> least most) network devices? If it's only for a subset of NICs, how
> can one tell whether a given driver needs forward progress guarantee
> or not?
>
> * I assume that wireless drivers aren't and can't be used in this
> fashion. Is that a correction assumption?
>

People do mount NFS over wireless interfaces. It's not terribly common
though, in my experience.

--
Jeff Layton <jlayton@xxxxxxxxxxxxxxx>