From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753493AbcHBKJe (ORCPT ); Tue, 2 Aug 2016 06:09:34 -0400 Received: from mx2.suse.de ([195.135.220.15]:51600 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752065AbcHBKIk (ORCPT ); Tue, 2 Aug 2016 06:08:40 -0400 Message-ID: <1470132203.30985.16.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 12:03:23 +0200 In-Reply-To: <20160802081801.GC12403@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> 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 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. Regards Oliver