From: Mike Snitzer <snitzer@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>,
Junaid Shahid <junaids@google.com>,
Alasdair Kergon <agk@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: dm ioctl: Restore __GFP_HIGH in copy_params()
Date: Mon, 22 May 2017 19:35:57 -0400 [thread overview]
Message-ID: <20170522233557.GA26990@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1705221325200.30407@chino.kir.corp.google.com>
On Mon, May 22 2017 at 4:35pm -0400,
David Rientjes <rientjes@google.com> 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
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>,
Junaid Shahid <junaids@google.com>,
Alasdair Kergon <agk@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: dm ioctl: Restore __GFP_HIGH in copy_params()
Date: Mon, 22 May 2017 19:35:57 -0400 [thread overview]
Message-ID: <20170522233557.GA26990@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1705221325200.30407@chino.kir.corp.google.com>
On Mon, May 22 2017 at 4:35pm -0400,
David Rientjes <rientjes@google.com> 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
next prev parent reply other threads:[~2017-05-22 23:36 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170518185040.108293-1-junaids@google.com>
2017-05-18 19:00 ` [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() 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 2:50 ` Junaid Shahid
2017-05-19 7:46 ` Michal Hocko
2017-05-19 7:46 ` Michal Hocko
2017-05-19 23:43 ` Mikulas Patocka
2017-05-19 23:43 ` Mikulas Patocka
2017-05-22 9:37 ` Michal Hocko
2017-05-22 9:37 ` Michal Hocko
2017-05-22 12:00 ` Mikulas Patocka
2017-05-22 12:00 ` Mikulas Patocka
2017-05-22 12:09 ` Michal Hocko
2017-05-22 12:09 ` Michal Hocko
2017-05-22 14:52 ` Mikulas Patocka
2017-05-22 14:52 ` Mikulas Patocka
2017-05-22 15:03 ` Michal Hocko
2017-05-22 15:03 ` Michal Hocko
2017-05-22 18:04 ` Mike Snitzer
2017-05-22 18:04 ` Mike Snitzer
2017-05-22 20:35 ` David Rientjes
2017-05-22 20:35 ` David Rientjes
2017-05-22 23:35 ` Mike Snitzer [this message]
2017-05-22 23:35 ` Mike Snitzer
2017-05-23 6:05 ` Michal Hocko
2017-05-23 6:05 ` Michal Hocko
2017-05-23 16:44 ` Mikulas Patocka
2017-05-23 16:44 ` Mikulas Patocka
2017-05-25 8:58 ` Michal Hocko
2017-05-25 8:58 ` Michal Hocko
2017-05-23 6:49 ` Michal Hocko
2017-05-23 6:49 ` Michal Hocko
[not found] ` <alpine.LRH.2.02.1705191949340.17646@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <20170520083412.GD11925@dhcp22.suse.cz>
2017-05-20 19:00 ` [PATCH] " Mikulas Patocka
2017-05-20 19:00 ` Mikulas Patocka
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=20170522233557.GA26990@redhat.com \
--to=snitzer@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=mpatocka@redhat.com \
--cc=rientjes@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.