linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Mikulas Patocka <mpatocka@redhat.com>
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: Mon, 22 May 2017 17:03:22 +0200	[thread overview]
Message-ID: <20170522150321.GM8509@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.LRH.2.02.1705221026430.20076@file01.intranet.prod.int.rdu2.redhat.com>

On Mon 22-05-17 10:52:44, Mikulas Patocka wrote:
> 
> 
> On Mon, 22 May 2017, Michal Hocko wrote:
[...] 
> > I am not sure I understand. OOM killer is invoked for _all_ allocations
> > <= PAGE_ALLOC_COSTLY_ORDER that do not have __GFP_NORETRY as long as the
> > OOM killer is not disabled (oom_killer_disable) and that only happens
> > from the PM suspend path which makes sure that no userspace is active at
> > the time. AFAIU this is a userspace triggered path and so the later
> > shouldn't apply to it and GFP_KERNEL should be therefore sufficient.
> > Relying to a portion of memory reserves to prevent from deadlock seems
> > fundamentaly broken  to me.
> > 
> 
> 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).

But let me repeat. GFP_KERNEL allocation for order-0 page will not fail.
If you need non-failing semantic then just make it clear by adding
__GFP_NOFAIL rather than __GFP_HIGH. Memory reserves are a scarce
resource and there are users which might really need it from atomic
contexts.

Anyway, this is not the code I am maintaining so I will not argue more
and won't nack the patch. But is smells like a pure cargo cult, to be
honest.

If you really insist, though, I would just ask to have a more detailed
explanation why it is _believed_ the flag is needed because the vague
"Use __GFP_HIGH to avoid low memory issues when a device is suspended
and the ioctl is needed to resume it." doesn't really clarify much to be
honest.

Thanks!
-- 
Michal Hocko
SUSE Labs

--
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-22 15:03 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
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 [this message]
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=20170522150321.GM8509@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --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=mpatocka@redhat.com \
    --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