LKML Archive on
help / color / mirror / Atom feed
From: Tetsuo Handa <>
Subject: Re: [PATCH 1/2] mm: Allow small allocations to fail
Date: Thu, 12 Mar 2015 21:54:47 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

(The Cc: line seems to be partially truncated. Please re-add if needed.)

Michal Hocko wrote:
> Finally, if a non-failing allocation is unavoidable then __GFP_NOFAIL
> flag is there to express this strong requirement. It is much better to
> have a simple way to check all those places and come up with a solution
> which will guarantee a forward progress for them.

Keeping gfp flags passed to ongoing allocation inside "struct task_struct"
will allow the OOM killer to skip OOM victims doing __GFP_NOFAIL. would give a hint.

> As this behavior is established for many years we cannot change it
> immediately. This patch instead exports a new sysctl/proc knob which
> tells allocator how much to retry. The higher the number the longer will
> the allocator loop and try to trigger OOM killer when the memory is too
> low. This implementation counts only those retries which involved OOM
> killer because we do not want to be too eager to fail the request.

I prefer jiffies timeouts than retry counts, for jiffies will allow vmcore
to tell how long the process was stalled for memory allocation. and would give a hint.

> The default value is ULONG_MAX which basically preserves the current
> behavior (endless retries). The idea is that we start with testing
> systems first and lower the value to catch potential fallouts (crashes
> due to unchecked failures or other misbehavior like FS ro-remounts
> etc...). Allocation failures are already reported by warn_alloc_failed
> so we should be able to catch the allocation path before an issue is
> triggered.

Few developers are using fault-injection capability (CONFIG_FAILSLAB and
CONFIG_FAIL_PAGE_ALLOC). Even less developers would be performing OOM
stress tests. Printing allocation failure messages only upon OOM condition
is Whack-A-Mole where moles remain hidden until distribution kernel users
by chance (or by intent) triggered OOM condition.

I tried SystemTap-based mandatory fault-injection hooks at and I reported
random crashes at .
How can we find the exact culprit allocation when an issue is triggered
some time after the first failure messages?

I think that your knob helps avoiding infinite loop if lower value is
given, but I don't think that your knob helps catching potential fallouts.

> We will try to encourage distributions to change the default in the
> second step so that we get a much bigger exposure.

Can we expect that distribution kernel users are willing to perform OOM
stress tests which kernel developers did not perform?

> And finally we can change the default in the kernel while still keeping
> the knob for conservative configurations. This will be long run but
> let's start.

And finally what patches will you propose for already running systems
using distribution kernels? I can't wait for years (or decades) until
your knob and fixes for fallouts are backported.

  reply	other threads:[~2015-03-12 12:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-11 20:54 [PATCH 0/2] Move away from non-failing small allocations Michal Hocko
2015-03-11 20:54 ` [PATCH 1/2] mm: Allow small allocations to fail Michal Hocko
2015-03-12 12:54   ` Tetsuo Handa [this message]
2015-03-12 13:12     ` Michal Hocko
2015-03-15  5:43   ` Tetsuo Handa
2015-03-15 12:13     ` Michal Hocko
2015-03-15 13:06       ` Tetsuo Handa
2015-03-16  7:46         ` [PATCH 1/2 v2] " Michal Hocko
2015-03-16 21:11           ` Johannes Weiner
2015-03-17 10:25             ` Michal Hocko
2015-03-17 13:29               ` Johannes Weiner
2015-03-17 14:17                 ` Michal Hocko
2015-03-17 17:26                   ` Johannes Weiner
2015-03-17 19:41                     ` Michal Hocko
2015-03-18  9:10                       ` Vlastimil Babka
2015-03-18 12:04                         ` Michal Hocko
2015-03-18 12:36                         ` Tetsuo Handa
2015-03-18 11:35                       ` Tetsuo Handa
2015-03-17 11:13           ` Tetsuo Handa
2015-03-17 13:15             ` Michal Hocko
2015-03-18 11:33               ` Tetsuo Handa
2015-03-18 12:23                 ` Michal Hocko
2015-03-19 11:03                   ` Tetsuo Handa
2015-03-11 20:54 ` [PATCH 2/2] mmotm: Enable small allocation " Michal Hocko
2015-03-11 22:36 ` [PATCH 0/2] Move away from non-failing small allocations Sasha Levin
2015-03-16 22:38 ` Andrew Morton
2015-03-17  9:07   ` Michal Hocko
2015-03-17 14:06     ` Tetsuo Handa
2015-04-02 11:53       ` Tetsuo Handa

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).