From: Tejun Heo <tj@kernel.org>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: "David S. Miller" <davem@davemloft.net>,
Trond Myklebust <trond.myklebust@primarydata.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Anna Schumaker <anna.schumaker@netapp.com>,
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: Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers
Date: Fri, 18 Mar 2016 16:46:23 -0400 [thread overview]
Message-ID: <20160318204623.GM20028@mtj.duckdns.org> (raw)
In-Reply-To: <20160317213216.731d1fcc@synchrony.poochiereds.net>
Hello, Jeff.
On Thu, Mar 17, 2016 at 09:32:16PM -0400, Jeff Layton wrote:
> > * 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.
But does that actually work? It's pointless to add WQ_MEM_RECLAIM to
workqueues unless all other things are also guaranteed to make forward
progress regardless of memory pressure.
> > * 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.
Ditto, I'm very skeptical that this actually works in practice and
people expect and depend on it. I don't follow wireless development
closely but haven't heard anyone talking about reserving memory pools
or people complaining about wireless being the cause of OOM.
So, I really want to avoid spraying WQ_MEM_RECLAIM if it doesn't serve
actual purposes. It's wasteful, sets bad precedences and confuses
future readers.
Thanks.
--
tejun
next prev parent reply other threads:[~2016-03-18 20:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-17 16:45 Tejun Heo
2016-03-18 1:32 ` Jeff Layton
2016-03-18 20:46 ` Tejun Heo [this message]
2016-03-18 21:24 ` J. Bruce Fields
2016-03-20 18:55 ` Tejun Heo
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=20160318204623.GM20028@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
all inboxes | Powered by JetHome®