On Tue, 2016-08-02 at 14:48 +0200, Michal Hocko wrote: > On Tue 02-08-16 13:44:48, Oliver Neukum wrote: > > On Tue, 2016-08-02 at 13:34 +0200, Michal Hocko wrote: > > > On Tue 02-08-16 12:03:23, Oliver Neukum wrote: > > > > On Tue, 2016-08-02 at 10:18 +0200, Michal Hocko wrote: > > > > > On Tue 02-08-16 10:06:12, Oliver Neukum wrote: > > > > > > On Mon, 2016-08-01 at 10:20 -0400, Tejun Heo wrote: > > > > > > > Hello, > > > > > > > > > > > > > > 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 > > > > > > > > > > > > It cannot. The IO must be described to the hardware with a data > > > > > > structure in memory. > > > > > > > > > > > > > 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? > > > > > > > > > > > > We had actual deadlocks with GFP_KERNEL. It seems to me that the SCSI > > > > > > layer can deal with IO that cannot be completed due to a lack of memory > > > > > > at least somewhat, but a deadlock within a driver would obviously be > > > > > > deadly. So I don't think that mempools would remove the need for > > > > > > GFP_NOIO as there are places in usbcore we cannot enter the page > > > > > > laundering path from. They are an additional need. > > > > > > > > > > OK, I guess there is some misunderstanding here. I believe that Tejun > > > > > wasn't arguing to drop GFP_NOIO. It might be really needed for the dead > > > > > lock avoidance. No question about that. The whole point is that > > > > > WQ_RECLAIM might be completely pointless because a rescuer wouldn't help > > > > > much if the work item would do GFP_NOIO and get stuck in the page > > > > > allocator. > > > > > > > > But that can be a problem only if the items on the work queue are > > > > actually run and without WQ_MEM_RECLAIM that guarantee cannot be made. > > > > We can deal with failures of memory allocation. But the requests > > > > must actually terminate. > > > > > > I think you have missed my point. So let me ask differently. What is the > > > difference between your work item not running at all or looping > > > endlessly with GFP_NOIO inside the page allocator? If that particular > > > work item is necessary for the further progress then the system is > > > screwed one way or another. > > > > The key difference is that I could give the right parameters to the > > kmalloc() call. If it doesn't run, I am surely screwed. Thus I conclude > > that WQ_RECLAIM needs to be set. > > Just to make sure I understand. So you will never call kmalloc with > __GFP_DIRECT_RECLAIM from the rescuer context, right? Apparently if that is the requirement USB will have to define its own set of flags to use in such contexts. But still the calls as currently executed work. Taking away WQ_MEM_RECLAIM would create danger of introducing a regression. The issue with __GFP_DIRECT_RECLAIM already exists and can be fixed. Regards Oliver -- 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
