[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160801142005.GB2542@mtj.duckdns.org>
Date: Mon, 1 Aug 2016 10:20:05 -0400
From: Tejun Heo <tj@...nel.org>
To: Michal Hocko <mhocko@...nel.org>
Cc: Alan Stern <stern@...land.harvard.edu>,
Oliver Neukum <oneukum@...e.com>,
Bhaktipriya Shridhar <bhaktipriya96@...il.com>,
Geliang Tang <geliangtang@....com>,
"GeyslanG.Bem@...yakshetra" <geyslan@...il.com>,
Masanari Iida <standby24x7@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Mel Gorman <mgorman@...hsingularity.net>,
Saurabh Karajgaonkar <skarajga@...teon.com>,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
Johannes Weiner <hannes@...xchg.org>
Subject: Re: [RFC] usb: host: u132-hcd: Remove deprecated
create_singlethread_workqueue
Hello,
On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > All that would do is deferring the deadlock, right? I'm not sure it
> > makes a lot of sense to protect an IO path against memory pressure
> > half-way. It either can be depended during memory reclaim or it
> > can't.
>
> Completely agreed! If the rescuer thread can block on a memory
> allocation be it GFP_NOIO or others it is basically useless.
...
> > Can MM people please chime in? The question is about USB stoage
> > devices and memory reclaim. USB doesn't guarantee forward progress
> > under memory pressure but tries a best-effort attempt with GFP_NOIO
> > and ATOMIC. Is this the right thing to do?
>
> If any real IO depends on those devices then this is not sufficient and
> they need some form of guarantee for progress (aka mempool).
Oliver, Alan, what do you think? If USB itself can't operate without
allocating memory during transactions, whatever USB storage drivers
are doing isn't all that meaningful. Can we proceed with the
workqueue patches? Also, it could be that the only thing GFP_NOIO and
GFP_ATOMIC are doing is increasing the chance of IO failures under
memory pressure. Maybe it'd be a good idea to reconsider the
approach?
Thanks.
--
tejun
Powered by blists - more mailing lists