From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754858AbcHATaZ (ORCPT ); Mon, 1 Aug 2016 15:30:25 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:37361 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751928AbcHATaQ (ORCPT ); Mon, 1 Aug 2016 15:30:16 -0400 Date: Mon, 1 Aug 2016 20:28:09 +0200 From: Michal Hocko To: Alan Stern Cc: Tejun Heo , Oliver Neukum , Bhaktipriya Shridhar , Geliang Tang , "GeyslanG.Bem@Karyakshetra" , Masanari Iida , Greg Kroah-Hartman , Vlastimil Babka , Mel Gorman , Saurabh Karajgaonkar , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, Johannes Weiner Subject: Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue Message-ID: <20160801182809.GC31957@dhcp22.suse.cz> References: <20160801142005.GB2542@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon 01-08-16 14:00:57, Alan Stern wrote: > On Mon, 1 Aug 2016, Tejun Heo wrote: > > > Hello, > > > > On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote: > > > > All that would do is deferring the deadlock, right? I'm not sure it > > > > makes a lot of sense to protect an IO path against memory pressure > > > > half-way. It either can be depended during memory reclaim or it > > > > can't. > > > > > > Completely agreed! If the rescuer thread can block on a memory > > > allocation be it GFP_NOIO or others it is basically useless. > > ... > > > > Can MM people please chime in? The question is about USB stoage > > > > devices and memory reclaim. USB doesn't guarantee forward progress > > > > under memory pressure but tries a best-effort attempt with GFP_NOIO > > > > and ATOMIC. Is this the right thing to do? > > > > > > 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 > > 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? > > I agree that USB's approach to memory allocation won't prevent failures > when there is severe pressure. Or even worse, silent hangs for GFP_NOIO requests. If the allocation size that is issued from that context is not large (basically < order-4) then the allocation would be retried basically for ever without invoking the OOM killer. Now, this is rather unlikely to become a real problem unless there is a serious flood of these GFP_NOIO allocation requests. But the main point remains. GFP_NOIO doesn't guanratee a forward progress. Success of such an allocation depends on on a different context with the full reclaim capabilities (including the OOM killer). -- Michal Hocko SUSE Labs