Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1647363

Re: dm ioctl: Restore __GFP_HIGH in copy_params()

From David Rientjes <rientjes@google.com>
Newsgroups linux.kernel
Subject Re: dm ioctl: Restore __GFP_HIGH in copy_params()
Date 2017-05-22 22:40 +0200
Message-ID <tK2ht-1Tl-37@gated-at.bofh.it> (permalink)
References (6 earlier) <tJUjU-5vZ-21@gated-at.bofh.it> <tJUtA-5zo-25@gated-at.bofh.it> <tJWYp-6XB-3@gated-at.bofh.it> <tJX87-7gH-29@gated-at.bofh.it> <tJZWi-z3-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() Junaid Shahid <junaids@google.com> - 2017-05-19 05:00 +0200
  Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() Michal Hocko <mhocko@kernel.org> - 2017-05-19 09:50 +0200
    Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() Mikulas Patocka <mpatocka@redhat.com> - 2017-05-20 01:50 +0200
      Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() Michal Hocko <mhocko@kernel.org> - 2017-05-22 11:40 +0200
        Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() Mikulas Patocka <mpatocka@redhat.com> - 2017-05-22 14:10 +0200
          Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() Michal Hocko <mhocko@kernel.org> - 2017-05-22 14:20 +0200
            Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() Mikulas Patocka <mpatocka@redhat.com> - 2017-05-22 17:00 +0200
              Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params() Michal Hocko <mhocko@kernel.org> - 2017-05-22 17:10 +0200
                Re: dm ioctl: Restore __GFP_HIGH in copy_params() Mike Snitzer <snitzer@redhat.com> - 2017-05-22 20:10 +0200
                Re: dm ioctl: Restore __GFP_HIGH in copy_params() David Rientjes <rientjes@google.com> - 2017-05-22 22:40 +0200
                Re: dm ioctl: Restore __GFP_HIGH in copy_params() Mike Snitzer <snitzer@redhat.com> - 2017-05-23 01:40 +0200
                Re: dm ioctl: Restore __GFP_HIGH in copy_params() Michal Hocko <mhocko@kernel.org> - 2017-05-23 08:10 +0200
                Re: dm ioctl: Restore __GFP_HIGH in copy_params() Mikulas Patocka <mpatocka@redhat.com> - 2017-05-23 18:50 +0200
                Re: dm ioctl: Restore __GFP_HIGH in copy_params() Michal Hocko <mhocko@kernel.org> - 2017-05-23 09:00 +0200

csiph-web