From: Chris Down <chris@chrisdown.name>
To: Axel Rasmussen <axelrasmussen@google.com>
Cc: cgroups@vger.kernel.org, hannes@cmpxchg.org, kernel-team@fb.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
yuzhao@google.com
Subject: Re: MGLRU premature memcg OOM on slow writes
Date: Fri, 1 Mar 2024 00:30:53 +0000 [thread overview]
Message-ID: <ZeEhvV15IWllPKvM@chrisdown.name> (raw)
In-Reply-To: <20240229235134.2447718-1-axelrasmussen@google.com>
Axel Rasmussen writes:
>A couple of dumb questions. In your test, do you have any of the following
>configured / enabled?
>
>/proc/sys/vm/laptop_mode
>memory.low
>memory.min
None of these are enabled. The issue is trivially reproducible by writing to
any slow device with memory.max enabled, but from the code it looks like MGLRU
is also susceptible to this on global reclaim (although it's less likely due to
page diversity).
>Besides that, it looks like the place non-MGLRU reclaim wakes up the
>flushers is in shrink_inactive_list() (which calls wakeup_flusher_threads()).
>Since MGLRU calls shrink_folio_list() directly (from evict_folios()), I agree it
>looks like it simply will not do this.
>
>Yosry pointed out [1], where MGLRU used to call this but stopped doing that. It
>makes sense to me at least that doing writeback every time we age is too
>aggressive, but doing it in evict_folios() makes some sense to me, basically to
>copy the behavior the non-MGLRU path (shrink_inactive_list()) has.
Thanks! We may also need reclaim_throttle(), depending on how you implement it.
Current non-MGLRU behaviour on slow storage is also highly suspect in terms of
(lack of) throttling after moving away from VMSCAN_THROTTLE_WRITEBACK, but one
thing at a time :-)
next prev parent reply other threads:[~2024-03-01 0:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-09 2:31 MGLRU premature memcg OOM on slow writes Chris Down
2024-02-29 17:28 ` Chris Down
2024-02-29 23:51 ` Axel Rasmussen
2024-03-01 0:30 ` Chris Down [this message]
2024-03-08 19:18 ` Axel Rasmussen
2024-03-08 21:22 ` Johannes Weiner
2024-03-11 9:11 ` Yafang Shao
2024-03-12 16:44 ` Axel Rasmussen
2024-03-12 20:07 ` Yu Zhao
2024-03-12 20:11 ` Yu Zhao
2024-03-13 3:33 ` Yafang Shao
2024-03-14 22:23 ` Yu Zhao
2024-03-15 2:38 ` Yafang Shao
2024-03-15 14:27 ` Johannes Weiner
2024-03-12 21:08 ` Johannes Weiner
2024-03-13 2:08 ` Yu Zhao
2024-03-13 3:22 ` Johannes Weiner
2024-03-13 10:59 ` Hillf Danton
2024-03-01 11:25 ` Hillf Danton
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=ZeEhvV15IWllPKvM@chrisdown.name \
--to=chris@chrisdown.name \
--cc=axelrasmussen@google.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=yuzhao@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).