From: Michal Hocko <mhocko@kernel.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
"Artem S. Tashkinov" <aros@gmx.com>,
linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure
Date: Tue, 6 Aug 2019 11:29:30 +0200 [thread overview]
Message-ID: <20190806092930.GO11812@dhcp22.suse.cz> (raw)
In-Reply-To: <20190805185542.GA4128@cmpxchg.org>
On Mon 05-08-19 14:55:42, Johannes Weiner wrote:
> On Mon, Aug 05, 2019 at 03:31:19PM +0200, Michal Hocko wrote:
> > On Mon 05-08-19 14:13:16, Vlastimil Babka wrote:
> > > On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
> > > > Hello,
> > > >
> > > > There's this bug which has been bugging many people for many years
> > > > already and which is reproducible in less than a few minutes under the
> > > > latest and greatest kernel, 5.2.6. All the kernel parameters are set to
> > > > defaults.
> > > >
> > > > Steps to reproduce:
> > > >
> > > > 1) Boot with mem=4G
> > > > 2) Disable swap to make everything faster (sudo swapoff -a)
> > > > 3) Launch a web browser, e.g. Chrome/Chromium or/and Firefox
> > > > 4) Start opening tabs in either of them and watch your free RAM decrease
> > > >
> > > > Once you hit a situation when opening a new tab requires more RAM than
> > > > is currently available, the system will stall hard. You will barely be
> > > > able to move the mouse pointer. Your disk LED will be flashing
> > > > incessantly (I'm not entirely sure why). You will not be able to run new
> > > > applications or close currently running ones.
> > >
> > > > This little crisis may continue for minutes or even longer. I think
> > > > that's not how the system should behave in this situation. I believe
> > > > something must be done about that to avoid this stall.
> > >
> > > Yeah that's a known problem, made worse SSD's in fact, as they are able
> > > to keep refaulting the last remaining file pages fast enough, so there
> > > is still apparent progress in reclaim and OOM doesn't kick in.
> > >
> > > At this point, the likely solution will be probably based on pressure
> > > stall monitoring (PSI). I don't know how far we are from a built-in
> > > monitor with reasonable defaults for a desktop workload, so CCing
> > > relevant folks.
> >
> > Another potential approach would be to consider the refault information
> > we have already for file backed pages. Once we start reclaiming only
> > workingset pages then we should be trashing, right? It cannot be as
> > precise as the cost model which can be defined around PSI but it might
> > give us at least a fallback measure.
>
> NAK, this does *not* work. Not even as fallback.
>
> There is no amount of refaults for which you can say whether they are
> a problem or not. It depends on the disk speed (obvious) but also on
> the workload's memory access patterns (somewhat less obvious).
>
> For example, we have workloads whose cache set doesn't quite fit into
> memory, but everything else is pretty much statically allocated and it
> rarely touches any new or one-off filesystem data. So there is always
> a steady rate of mostly uninterrupted refaults, however, most data
> accesses are hitting the cache! And we have fast SSDs that compensate
> for the refaults that do occur. The workload runs *completely fine*.
OK, thanks for this example. I can see how a constant working set
refault can work properly if the rate is slower than the overal IO
plus the allocation demand for other purpose.
Thanks!
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-08-06 9:29 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 [this message]
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
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=20190806092930.GO11812@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=aros@gmx.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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).