From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966887AbcHBNuO (ORCPT ); Tue, 2 Aug 2016 09:50:14 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:36965 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966835AbcHBNt5 (ORCPT ); Tue, 2 Aug 2016 09:49:57 -0400 Date: Tue, 2 Aug 2016 14:48:20 +0200 From: Michal Hocko To: Oliver Neukum Cc: Geliang Tang , Johannes Weiner , Bhaktipriya Shridhar , "GeyslanG.Bem@Karyakshetra" , Masanari Iida , Tejun Heo , Greg Kroah-Hartman , Alan Stern , Vlastimil Babka , Mel Gorman , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, Saurabh Karajgaonkar Subject: Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue Message-ID: <20160802124819.GM12403@dhcp22.suse.cz> References: <20160727192308.GP4144@mtj.duckdns.org> <20160729131147.GJ2542@mtj.duckdns.org> <20160801135036.GH13544@dhcp22.suse.cz> <20160801142005.GB2542@mtj.duckdns.org> <1470125172.30985.4.camel@suse.com> <20160802081801.GC12403@dhcp22.suse.cz> <1470132203.30985.16.camel@suse.com> <20160802113409.GF12403@dhcp22.suse.cz> <1470138288.30985.18.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1470138288.30985.18.camel@suse.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? -- Michal Hocko SUSE Labs