linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Junaid Shahid <junaids@google.com>,
	David Rientjes <rientjes@google.com>,
	Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	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()
Date: Fri, 19 May 2017 19:43:23 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1705191934340.17646@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <20170519074647.GC13041@dhcp22.suse.cz>



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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-05-19 23:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170518185040.108293-1-junaids@google.com>
2017-05-18 19:00 ` Junaid Shahid
     [not found] ` <20170518190406.GB2330@dhcp22.suse.cz>
     [not found]   ` <alpine.DEB.2.10.1705181338090.132717@chino.kir.corp.google.com>
2017-05-19  2:50     ` Junaid Shahid
2017-05-19  7:46       ` Michal Hocko
2017-05-19 23:43         ` Mikulas Patocka [this message]
2017-05-22  9:37           ` Michal Hocko
2017-05-22 12:00             ` Mikulas Patocka
2017-05-22 12:09               ` Michal Hocko
2017-05-22 14:52                 ` Mikulas Patocka
2017-05-22 15:03                   ` Michal Hocko
2017-05-22 18:04                     ` Mike Snitzer
2017-05-22 20:35                       ` David Rientjes
2017-05-22 23:35                         ` Mike Snitzer
2017-05-23  6:05                         ` Michal Hocko
2017-05-23 16:44                           ` Mikulas Patocka
2017-05-25  8:58                             ` Michal Hocko
2017-05-23  6:49                       ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.02.1705191934340.17646@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=agk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreslc@google.com \
    --cc=gthelen@google.com \
    --cc=junaids@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=rientjes@google.com \
    --cc=snitzer@redhat.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox