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> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
