From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756751AbcHBRKs (ORCPT ); Tue, 2 Aug 2016 13:10:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:46657 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932445AbcHBLt0 (ORCPT ); Tue, 2 Aug 2016 07:49:26 -0400 Message-ID: <1470138288.30985.18.camel@suse.com> Subject: Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue From: Oliver Neukum To: Michal Hocko 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 Date: Tue, 02 Aug 2016 13:44:48 +0200 In-Reply-To: <20160802113409.GF12403@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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Regards Oliver