lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ