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. However, is it possible that the _type_ of failure might be more transparent? With GFP_NOIO, you end up with a cascading series of allocation errors and it's obvious that something has gone very wrong. If we were to switch to GFP_KERNEL, page-out could lead to deadlock with no diagnostics (except perhaps for a watchdog warning). Regardless, I would like to hear Oliver's thoughts. Alan Stern -- 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
