netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: "David S. Miller" <davem@davemloft.net>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Jeff Layton <jlayton@poochiereds.net>,
	Anna Schumaker <anna.schumaker@netapp.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-nfs@vger.kernel.org,
	Amitoj Kaur Chawla <amitoj1606@gmail.com>,
	kernel-team@fb.com, Johannes Weiner <hannes@cmpxchg.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Eva Rachel Retuya <eraretuya@gmail.com>,
	Bhaktipriya Shridhar <bhaktipriya96@gmail.com>,
	linux-wireless@vger.kernel.org
Subject: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers
Date: Thu, 17 Mar 2016 09:45:46 -0700	[thread overview]
Message-ID: <20160317164546.GT21104@mtj.duckdns.org> (raw)

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?

* 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?

Thanks.

-- 
tejun

             reply	other threads:[~2016-03-17 16:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-17 16:45 Tejun Heo [this message]
     [not found] ` <20160317164546.GT21104-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-03-18  1:32   ` [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers Jeff Layton
     [not found]     ` <20160317213216.731d1fcc-08S845evdOaAjSkqwZiSMmfYqLom42DlXqFh9Ls21Oc@public.gmane.org>
2016-03-18 20:46       ` Tejun Heo
     [not found]         ` <20160318204623.GM20028-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-03-18 21:24           ` J. Bruce Fields
2016-03-20 18:55             ` Tejun Heo
     [not found]               ` <20160320185507.GT20028-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-03-24 14:22                 ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160317164546.GT21104@mtj.duckdns.org \
    --to=tj@kernel.org \
    --cc=amitoj1606@gmail.com \
    --cc=anna.schumaker@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=bhaktipriya96@gmail.com \
    --cc=davem@davemloft.net \
    --cc=eraretuya@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=jlayton@poochiereds.net \
    --cc=johannes@sipsolutions.net \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).