From: ndrw <ndrw.xf@redhazel.co.uk>
To: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
"Artem S. Tashkinov" <aros@gmx.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure
Date: Sat, 10 Aug 2019 13:34:06 +0100 [thread overview]
Message-ID: <33407eca-3c05-5900-0353-761db62feeea@redhazel.co.uk> (raw)
In-Reply-To: <20190809105016.GP18351@dhcp22.suse.cz>
On 09/08/2019 11:50, Michal Hocko wrote:
> We try to protect low amount of cache. Have a look at get_scan_count
> function. But the exact amount of the cache to be protected is really
> hard to know wihtout a crystal ball or understanding of the workload.
> The kernel doesn't have neither of the two.
Thank you. I'm familiarizing myself with the code. Is there anyone I
could discuss some details with? I don't want to create too much noise here.
For example, are file pages created by mmaping files and are anon page
exclusively allocated on heap (RW data)? If so, where do "streaming IO"
pages belong to?
> We have been thinking about this problem for a long time and couldn't
> come up with anything much better than we have now. PSI is the most recent
> improvement in that area. If you have better ideas then patches are
> always welcome.
In general, I found there are very few user accessible knobs for
adjusting caching, especially in the pre-OOM phase. On the other hand,
swapping, dirty page caching, have many options or can even be disabled
completely.
For example, I would like to try disabling/limiting eviction of some/all
file pages (for example exec pages) akin to disabling swapping, but
there is no such mechanism. Yes, there would likely be problems with
large RO mmapped files that would need to be addressed, but in many
applications users would be interested in having such options.
Adjusting how aggressive/conservative the system should be with the OOM
killer also falls into this category.
>> [OOM killer accuracy]
> That is a completely orthogonal problem, I am afraid. So far we have
> been discussing _when_ to trigger OOM killer. This is _who_ to kill. I
> haven't heard any recent examples that the victim selection would be way
> off and killing something obviously incorrect.
You are right. I've assumed earlyoom is more accurate because of OOM
killer performing better on a system that isn't stalled yet (perhaps it
does). But actually, earlyoom doesn't trigger OOM killer at all:
https://github.com/rfjakob/earlyoom#why-not-trigger-the-kernel-oom-killer
Apparently some applications (chrome and electron-based tools) set their
oom_score_adj incorrectly - this matches my observations of OOM killer
behavior:
https://bugs.chromium.org/p/chromium/issues/detail?id=333617
> Something that other people can play with to reproduce the issue would
> be more than welcome.
This is the script I used. It reliably reproduces the issue:
https://github.com/ndrw6/import_postcodes/blob/master/import_postcodes.py
but it has quite a few dependencies, needs some input data and, in
general, does a lot more than just fill up the memory. I will try to
come up with something simpler.
Best regards,
ndrw
next prev parent reply other threads:[~2019-08-10 12:34 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-04 9:23 Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure Artem S. Tashkinov
2019-08-05 12:13 ` Vlastimil Babka
2019-08-05 13:31 ` Michal Hocko
2019-08-05 16:47 ` Suren Baghdasaryan
2019-08-05 18:55 ` Johannes Weiner
2019-08-06 9:29 ` Michal Hocko
2019-08-05 19:31 ` Johannes Weiner
2019-08-06 1:08 ` Suren Baghdasaryan
2019-08-06 9:36 ` Vlastimil Babka
2019-08-06 14:27 ` Johannes Weiner
2019-08-06 14:36 ` Michal Hocko
2019-08-06 16:27 ` Suren Baghdasaryan
2019-08-06 22:01 ` Johannes Weiner
2019-08-07 7:59 ` Michal Hocko
2019-08-07 20:51 ` Johannes Weiner
2019-08-07 21:01 ` Andrew Morton
2019-08-07 21:34 ` Johannes Weiner
2019-08-07 21:12 ` Johannes Weiner
2019-08-08 11:48 ` Michal Hocko
2019-08-08 15:10 ` ndrw.xf
2019-08-08 16:32 ` Michal Hocko
2019-08-08 17:57 ` ndrw.xf
2019-08-08 18:59 ` Michal Hocko
2019-08-08 21:59 ` ndrw
2019-08-09 8:57 ` Michal Hocko
2019-08-09 10:09 ` ndrw
2019-08-09 10:50 ` Michal Hocko
2019-08-09 14:18 ` Pintu Agarwal
2019-08-10 12:34 ` ndrw [this message]
2019-08-12 8:24 ` Michal Hocko
2019-08-10 21:07 ` ndrw
2021-07-24 17:32 ` Alexey Avramov
2019-08-08 14:47 ` Vlastimil Babka
2019-08-08 17:27 ` Johannes Weiner
2019-08-09 14:56 ` Vlastimil Babka
2019-08-09 17:31 ` Johannes Weiner
2019-08-13 13:47 ` Vlastimil Babka
2019-08-06 21:43 ` James Courtier-Dutton
2019-08-06 19:00 ` Florian Weimer
2019-08-20 6:46 ` Daniel Drake
2019-08-21 21:42 ` James Courtier-Dutton
2019-08-29 12:29 ` Michal Hocko
2019-09-02 20:15 ` Pavel Machek
2019-08-23 1:54 ` ndrw
2019-08-23 2:14 ` Daniel Drake
[not found] <20190805090514.5992-1-hdanton@sina.com>
2019-08-05 12:01 ` Artem S. Tashkinov
2019-08-06 8:57 Johannes Buchner
2019-08-06 19:43 Remi Gauvin
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=33407eca-3c05-5900-0353-761db62feeea@redhazel.co.uk \
--to=ndrw.xf@redhazel.co.uk \
--cc=akpm@linux-foundation.org \
--cc=aros@gmx.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=surenb@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 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).