linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Luigi Semenzato <semenzato@google.com>
Cc: Minchan Kim <minchan@kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: OOM kills with lots of free swap
Date: Tue, 27 Jun 2017 17:50:35 +0200	[thread overview]
Message-ID: <20170627155035.GA20189@dhcp22.suse.cz> (raw)
In-Reply-To: <CAA25o9TUkHd9w+DNBdH_4w6LTEEb+Q6QAycHcqx-z3mwh+G=kA@mail.gmail.com>

On Tue 27-06-17 08:22:36, Luigi Semenzato wrote:
> (sorry, I forgot to turn off HTML formatting)
> 
> Thank you, I can try this on ToT, although I think that the problem is
> not with the OOM killer itself but earlier---i.e. invoking the OOM
> killer seems unnecessary and wrong.  Here's the question.
> 
> The general strategy for page allocation seems to be (please correct
> me as needed):
> 
> 1. look in the free lists
> 2. if that did not succeed, try to reclaim, then try again to allocate
> 3. keep trying as long as progress is made (i.e. something was reclaimed)
> 4. if no progress was made and no pages were found, invoke the OOM killer.

Yes that is the case very broadly speaking. The hard question really is
what "no progress" actually means. We use "no pages could be reclaimed"
as the indicator. We cannot blow up at the first such instance of
course because that could be too early (e.g. data under writeback
and many other details). With 4.7+ kernels this is implemented in
should_reclaim_retry. Prior to the rework we used to rely on
zone_reclaimable which simply checked how many pages we have scanned
since the last page has been freed and if that is 6 times the
reclaimable memory then we simply give up. It had some issues described
in 0a0337e0d1d1 ("mm, oom: rework oom detection").

> I'd like to know if that "progress is made" notion is possibly buggy.
> Specifically, does it mean "progress is made by this task"?  Is it
> possible that resource contention creates a situation where most tasks
> in most cases can reclaim and allocate, but one task randomly fails to
> make progress?

This can happen, alhtough it is quite unlikely. We are trying to
throttle allocations but you can hardly fight a consistent badluck ;)

In order to see what is going on in your particular case we need an oom
report though.
-- 
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-06-27 15:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-23 23:29 OOM kills with lots of free swap Luigi Semenzato
2017-06-27  6:50 ` Vlastimil Babka
2017-06-27  7:11 ` Michal Hocko
2017-06-27 15:21   ` Luigi Semenzato
2017-06-27 15:22     ` Luigi Semenzato
2017-06-27 15:50       ` Michal Hocko [this message]
2017-06-29 17:46         ` Luigi Semenzato
2017-06-29 18:02           ` Luigi Semenzato

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=20170627155035.GA20189@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=semenzato@google.com \
    /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;
as well as URLs for NNTP newsgroup(s).