[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1458829358.9304.2.camel@sipsolutions.net>
Date: Thu, 24 Mar 2016 15:22:38 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Tejun Heo <tj@...nel.org>, "J. Bruce Fields" <bfields@...ldses.org>
Cc: Jeff Layton <jlayton@...chiereds.net>,
"David S. Miller" <davem@...emloft.net>,
Trond Myklebust <trond.myklebust@...marydata.com>,
Anna Schumaker <anna.schumaker@...app.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-nfs@...r.kernel.org,
Amitoj Kaur Chawla <amitoj1606@...il.com>,
kernel-team@...com, Johannes Weiner <hannes@...xchg.org>,
Eva Rachel Retuya <eraretuya@...il.com>,
Bhaktipriya Shridhar <bhaktipriya96@...il.com>,
linux-wireless@...r.kernel.org
Subject: Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers
On Sun, 2016-03-20 at 14:55 -0400, Tejun Heo wrote:
> If everything else is working, I'd be happy to throw in
> WQ_MEM_RECLAIM but I really don't want to add it if it doesn't
> actually achieve the goal. Can a wireless person chime in here?
>
I think for many wireless devices the workqueue, like for iwldvm that
was just changed, isn't in the packet path and thus less relevant.
For some, like SDIO based chips, it's more likely to be in the packet
path, so it would make sense to keep it.
Of course there's always a possibility of getting disconnected and then
not being able to re-establish the connection in memory pressure, but
that's not something we can control/predict (the disconnection). Can of
course also happen with wired if somebody pulls out the cable, but it's
less reliant on memory allocations to get back to working there, I
guess :)
johannes
Powered by blists - more mailing lists