From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762978AbdEVXgA (ORCPT ); Mon, 22 May 2017 19:36:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45544 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759940AbdEVXf7 (ORCPT ); Mon, 22 May 2017 19:35:59 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9EE8885365 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=msnitzer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9EE8885365 Date: Mon, 22 May 2017 19:35:57 -0400 From: Mike Snitzer To: David Rientjes Cc: Michal Hocko , Mikulas Patocka , Junaid Shahid , Alasdair Kergon , Andrew Morton , linux-mm@kvack.org, andreslc@google.com, gthelen@google.com, vbabka@suse.cz, linux-kernel@vger.kernel.org Subject: Re: dm ioctl: Restore __GFP_HIGH in copy_params() Message-ID: <20170522233557.GA26990@redhat.com> References: <1508444.i5EqlA1upv@js-desktop.svl.corp.google.com> <20170519074647.GC13041@dhcp22.suse.cz> <20170522093725.GF8509@dhcp22.suse.cz> <20170522120937.GI8509@dhcp22.suse.cz> <20170522150321.GM8509@dhcp22.suse.cz> <20170522180415.GA25340@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 22 May 2017 23:35:58 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 22 2017 at 4:35pm -0400, David Rientjes wrote: > On Mon, 22 May 2017, Mike Snitzer wrote: > > > > > The lvm2 was designed this way - it is broken, but there is not much that > > > > can be done about it - fixing this would mean major rewrite. The only > > > > thing we can do about it is to lower the deadlock probability with > > > > __GFP_HIGH (or PF_MEMALLOC that was used some times ago). > > > > Yes, lvm2 was originally designed to to have access to memory reserves > > to ensure forward progress. But if the mm subsystem has improved to > > allow for the required progress without lvm2 trying to stake a claim on > > those reserves then we'll gladly avoid (ab)using them. > > > > There is no such improvement to the page allocator when allocating at > runtime. A persistent amount of memory in a mempool could be set aside as > a preallocation and unavailable from the rest of the system forever as an > alternative to dynamically allocating with memory reserves, but that has > obvious downsides. This patch is the exact right thing to do. > > > > But let me repeat. GFP_KERNEL allocation for order-0 page will not fail. > > > > OK, but will it be serviced immediately? Not failing isn't useful if it > > never completes. > > > > No, and you can use __GFP_HIGH, which this patch does, to have a > reasonable expectation of forward progress in the very near term. > > > While adding the __GFP_NOFAIL flag would serve to document expectations > > I'm left unconvinced that the memory allocator will _not fail_ for an > > order-0 page -- as Mikulas said most ioctls don't need more than 4K. > > __GFP_NOFAIL would make no sense in kvmalloc() calls, ever, it would never > fallback to vmalloc :) > > I'm hoping this can get merged during the 4.12 window to fix the broken > commit d224e9381897. I've added your Acked-by and staged it for 4.12, please see: https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-4.12/dm&id=8c1e2162f27b319da913683143c0c6c09b083ebb Not sure when I'll send it to Linus but certainly no later than for rc4 inclusion. Thanks, Mike