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 -- 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
