From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755782AbcHBIbY (ORCPT ); Tue, 2 Aug 2016 04:31:24 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33316 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752020AbcHBIbO (ORCPT ); Tue, 2 Aug 2016 04:31:14 -0400 Date: Tue, 2 Aug 2016 10:18:01 +0200 From: Michal Hocko To: Oliver Neukum Cc: Tejun Heo , Geliang Tang , Johannes Weiner , Bhaktipriya Shridhar , "GeyslanG.Bem@Karyakshetra" , Masanari Iida , 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: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1470125172.30985.4.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 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. -- Michal Hocko SUSE Labs