Thread (5 messages) 5 messages, 3 authors, 2016-03-20

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

From: Tejun Heo <tj@kernel.org>
Date: 2016-03-18 20:46:29
Also in: linux-nfs, lkml, netdev

Hello, Jeff.

On Thu, Mar 17, 2016 at 09:32:16PM -0400, Jeff Layton wrote:
quoted
* 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.
quoted
* 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help