All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Jeff Layton <jeff.layton@primarydata.com>,
	lsf@lists.linux-foundation.org, Theodore Ts'o <tytso@mit.edu>,
	Dave Chinner <david@fromorbit.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-mm@kvack.org
Subject: RFC for small allocation failure mode transition plan (was: Re: [Lsf] common session about page allocator vs. FS/IO) It's time to put together the schedule)
Date: Sun, 8 Mar 2015 14:11:29 -0400	[thread overview]
Message-ID: <20150308181129.GA5751@dhcp22.suse.cz> (raw)
In-Reply-To: <1425311094.2187.11.camel@HansenPartnership.com>

On Mon 02-03-15 07:44:54, James Bottomley wrote:
> On Mon, 2015-03-02 at 10:41 -0500, Jeff Layton wrote:
> > On Mon, 2 Mar 2015 16:28:58 +0100
> > Michal Hocko <mhocko@suse.cz> wrote:
> > 
> > > [Let's add people from the discussion on the CC]
> > > 
> > > On Mon 02-03-15 07:26:33, James Bottomley wrote:
> > > > On Mon, 2015-03-02 at 16:19 +0100, Michal Hocko wrote:
> > > > > On Mon 23-02-15 18:08:42, Michal Hocko wrote:
[...]
> > > > > > I would like to propose a common session (FS and MM, maybe IO as well)
> > > > > > about memory allocator guarantees and the current behavior of the
> > > > > > page allocator with different gfp flags - GFP_KERNEL being basically
> > > > > > __GFP_NOFAIL for small allocations. __GFP_NOFAIL allocations in general
> > > > > > - how they are used in fs/io code paths and what can the allocator do
> > > > > > to prevent from memory exhaustion. GFP_NOFS behavior when combined with
> > > > > > __GFP_NOFAIL and so on. It seems there was a disconnection between mm
> > > > > > and fs people and one camp is not fully aware of what others are doing
> > > > > > and why as it turned out during recent discussions.
> > > > > 
> > > > > James do you have any plans to put this on the schedule?
> > > > 
> > > > I was waiting to see if there was any other feedback, but if you feel
> > > > strongly it should happen, I can do it.
> > > 
> > > I think it would be helpful, but let's see what other involved in the
> > > discussion think.
> > 
> > It makes sense to me as a plenary discussion.
> > 
> > I was personally quite surprised to hear that small allocations
> > couldn't fail, and dismayed at how much time I've spent writing dead
> > error handling code. ;)
> > 
> > If we're keen to get rid of that behavior (and I think it really ought
> > to go, IMNSHO), then what might make sense is to add a Kconfig switch
> > that allows small allocations to fail as an interim step and see what
> > breaks when it's enabled.
> > 
> > Once we fix all of those places up, then we can see about getting
> > distros to turn it on, and eventually eliminate the Kconfig switch
> > altogether. It'll take a few years, but that's probably the least
> > disruptive approach.
> 
> OK, your wish is my command: it's filled up the last empty plenary slot
> on Monday morning.

I guess the following RFC patch should be good for the first part of the
topic - Small allocations implying __GFP_NOFAIL currently. I am CCing
linux-mm mailing list as well so that people not attending LSF/MM can
comment on the approach.

I hope people will find time to look at it before the session because I
am afraid two topics per one slot will be too dense otherwise. I also
hope this part will be less controversial and the primary point for
discussion will be on HOW TO GET RID OF the current behavior in a sane
way rather than WHY TO KEEP IT.
---

      parent reply	other threads:[~2015-03-08 18:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1424395745.2603.27.camel@HansenPartnership.com>
     [not found] ` <54EAD453.6040907@suse.de>
2015-02-23 13:50   ` dm-mpath request merging concerns [was: Re: It's time to put together the schedule] Mike Snitzer
2015-02-23 17:18     ` [Lsf] " Mike Christie
2015-02-23 18:34       ` Benjamin Marzinski
2015-02-23 19:56         ` Mike Snitzer
2015-02-23 21:19           ` Benjamin Marzinski
2015-02-23 22:46             ` Mike Snitzer
2015-02-23 22:14               ` Benjamin Marzinski
2015-02-24  0:39                 ` Mike Snitzer
2015-02-24  0:38                   ` Benjamin Marzinski
2015-02-24  2:02                     ` Mike Snitzer
2015-02-24 14:35                       ` Jeff Moyer
2015-02-24 14:59                         ` Mike Snitzer
2015-02-23 19:35       ` [Lsf] " Merla, ShivaKrishna
2015-02-23 19:50       ` Mike Snitzer
2015-02-23 20:08         ` [Lsf] " Christoph Hellwig
2015-02-23 20:39           ` Mike Snitzer
2015-02-23 21:14             ` Mike Snitzer
     [not found] ` <20150223170842.GK24272@dhcp22.suse.cz>
     [not found]   ` <20150302151941.GB26343@dhcp22.suse.cz>
     [not found]     ` <1425309993.2187.3.camel@HansenPartnership.com>
     [not found]       ` <20150302152858.GF26334@dhcp22.suse.cz>
     [not found]         ` <20150302104154.3ae46eb7@tlielax.poochiereds.net>
     [not found]           ` <1425311094.2187.11.camel@HansenPartnership.com>
2015-03-08 18:11             ` Michal Hocko [this message]

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=20150308181129.GA5751@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=hannes@cmpxchg.org \
    --cc=jeff.layton@primarydata.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf@lists.linux-foundation.org \
    --cc=tytso@mit.edu \
    --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.