Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752016AbcCRBcY (ORCPT ); Thu, 17 Mar 2016 21:32:24 -0400 Received: from mail-yw0-f180.google.com ([209.85.161.180]:36774 "EHLO mail-yw0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751939AbcCRBcV (ORCPT ); Thu, 17 Mar 2016 21:32:21 -0400 Date: Thu, 17 Mar 2016 21:32:16 -0400 From: Jeff Layton To: Tejun Heo Cc: "David S. Miller" , Trond Myklebust , "J. Bruce Fields" , Anna Schumaker , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, Amitoj Kaur Chawla , kernel-team@fb.com, Johannes Weiner , Johannes Berg , Eva Rachel Retuya , Bhaktipriya Shridhar , linux-wireless@vger.kernel.org Subject: Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers Message-ID: <20160317213216.731d1fcc@synchrony.poochiereds.net> In-Reply-To: <20160317164546.GT21104@mtj.duckdns.org> References: <20160317164546.GT21104@mtj.duckdns.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1700 Lines: 41 On Thu, 17 Mar 2016 09:45:46 -0700 Tejun Heo 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