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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
