Messages in this thread | | | Date | Mon, 1 Aug 2016 20:28:09 +0200 | From | Michal Hocko <> | Subject | Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue |
| |
On Mon 01-08-16 14:00:57, Alan Stern wrote: > On Mon, 1 Aug 2016, Tejun Heo wrote: > > > 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? > > I agree that USB's approach to memory allocation won't prevent failures > when there is severe pressure.
Or even worse, silent hangs for GFP_NOIO requests. If the allocation size that is issued from that context is not large (basically < order-4) then the allocation would be retried basically for ever without invoking the OOM killer. Now, this is rather unlikely to become a real problem unless there is a serious flood of these GFP_NOIO allocation requests. But the main point remains. GFP_NOIO doesn't guanratee a forward progress. Success of such an allocation depends on on a different context with the full reclaim capabilities (including the OOM killer).
-- Michal Hocko SUSE Labs
| |