From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757432AbdESXne (ORCPT ); Fri, 19 May 2017 19:43:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43778 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751818AbdESXnc (ORCPT ); Fri, 19 May 2017 19:43:32 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 20474C049D5C Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mpatocka@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 20474C049D5C Date: Fri, 19 May 2017 19:43:23 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Michal Hocko cc: Junaid Shahid , David Rientjes , Alasdair Kergon , Mike Snitzer , Andrew Morton , linux-mm@kvack.org, andreslc@google.com, gthelen@google.com, vbabka@suse.cz, linux-kernel@vger.kernel.org Subject: Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() In-Reply-To: <20170519074647.GC13041@dhcp22.suse.cz> Message-ID: References: <20170518185040.108293-1-junaids@google.com> <20170518190406.GB2330@dhcp22.suse.cz> <1508444.i5EqlA1upv@js-desktop.svl.corp.google.com> <20170519074647.GC13041@dhcp22.suse.cz> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 19 May 2017 23:43:32 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 19 May 2017, Michal Hocko wrote: > On Thu 18-05-17 19:50:46, Junaid Shahid wrote: > > (Adding back the correct linux-mm email address and also adding linux-kernel.) > > > > On Thursday, May 18, 2017 01:41:33 PM David Rientjes wrote: > [...] > > > Let's ask Mikulas, who changed this from PF_MEMALLOC to __GFP_HIGH, > > > assuming there was a reason to do it in the first place in two different > > > ways. > > Hmm, the old PF_MEMALLOC used to have the following comment > /* > * Trying to avoid low memory issues when a device is > * suspended. > */ > > I am not really sure what that means but __GFP_HIGH certainly have a > different semantic than PF_MEMALLOC. The later grants the full access to > the memory reserves while the prior on partial access. If this is _really_ > needed then it deserves a comment explaining why. > -- > Michal Hocko > SUSE Labs Sometimes, I/O to a device mapper device is blocked until the userspace daemon dmeventd does some action (for example, when dm-mirror leg fails, dmeventd needs to mark the leg as failed in the lvm metadata and then reload the device). The dmeventd daemon mlocks itself in memory so that it doesn't generate any I/O. But it must be able to call ioctls. __GFP_HIGH is there so that the ioctls issued by dmeventd have higher chance of succeeding if some I/O is blocked, waiting for dmeventd action. It reduces the possibility of low-memory-deadlock, though it doesn't eliminate it entirely. Mikulas