From: Yosry Ahmed <yosryahmed@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Hocko" <mhocko@kernel.org>,
"Roman Gushchin" <roman.gushchin@linux.dev>,
"Shakeel Butt" <shakeelb@google.com>,
"Muchun Song" <muchun.song@linux.dev>,
"Ivan Babrou" <ivan@cloudflare.com>, "Tejun Heo" <tj@kernel.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Waiman Long" <longman@redhat.com>,
kernel-team@cloudflare.com, "Wei Xu" <weixugc@google.com>,
"Greg Thelen" <gthelen@google.com>,
"Domenico Cerasuolo" <cerasuolodomenico@gmail.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Yosry Ahmed" <yosryahmed@google.com>
Subject: [mm-unstable v4 0/5] mm: memcg: subtree stats flushing and thresholds
Date: Wed, 29 Nov 2023 03:21:48 +0000 [thread overview]
Message-ID: <20231129032154.3710765-1-yosryahmed@google.com> (raw)
This series attempts to address shortages in today's approach for memcg
stats flushing, namely occasionally stale or expensive stat reads. The
series does so by changing the threshold that we use to decide whether
to trigger a flush to be per memcg instead of global (patch 3), and then
changing flushing to be per memcg (i.e. subtree flushes) instead of
global (patch 5).
Patch 3 & 5 are the core of the series, and they include more details
and testing results. The rest are either cleanups or prep work.
This series replaces the "memcg: more sophisticated stats flushing"
series [1], which also replaces another series, in a long list of
attempts to improve memcg stats flushing. It is not a new version of
the same patchset as it is a completely different approach. This is
based on collected feedback from discussions on lkml in all previous
attempts. Hopefully, this is the final attempt.
There was a reported regression in v2 [2] for will-it-scale::fallocate
benchmark. I believe this regression should not affect production
workloads. This specific benchmark is allocating and freeing memory
(using fallocate/ftruncate) at a rate that is much faster to make actual
use of the memory. Testing this series on 100+ machines running
production workloads did not show any practical regressions in page
fault latency or allocation latency, but it showed great improvements in
stats read time. I do not have numbers about the exact improvements for
this series, but combined with another optimization for cgroup v1 [3] we
see 5-10x improvements. A significant chunk of that is coming from the
cgroup v1 optimization, but this series also made an improvement as
reported by Domenico [4].
v3 -> v4:
- Rebased on top of mm-unstable + "workload-specific and memory
pressure-driven zswap writeback" series to fix conflicts [5].
v3: https://lore.kernel.org/all/20231116022411.2250072-1-yosryahmed@google.com/
[1]https://lore.kernel.org/lkml/20230913073846.1528938-1-yosryahmed@google.com/
[2]https://lore.kernel.org/lkml/202310202303.c68e7639-oliver.sang@intel.com/
[3]https://lore.kernel.org/lkml/20230803185046.1385770-1-yosryahmed@google.com/
[4]https://lore.kernel.org/lkml/CAFYChMv_kv_KXOMRkrmTN-7MrfgBHMcK3YXv0dPYEL7nK77e2A@mail.gmail.com/
[5]https://lore.kernel.org/all/20231127234600.2971029-1-nphamcs@gmail.com/
Yosry Ahmed (5):
mm: memcg: change flush_next_time to flush_last_time
mm: memcg: move vmstats structs definition above flushing code
mm: memcg: make stats flushing threshold per-memcg
mm: workingset: move the stats flush into workingset_test_recent()
mm: memcg: restore subtree stats flushing
include/linux/memcontrol.h | 8 +-
mm/memcontrol.c | 272 +++++++++++++++++++++----------------
mm/vmscan.c | 2 +-
mm/workingset.c | 42 ++++--
4 files changed, 188 insertions(+), 136 deletions(-)
--
2.43.0.rc1.413.gea7ed67945-goog
next reply other threads:[~2023-11-29 3:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-29 3:21 Yosry Ahmed [this message]
2023-11-29 3:21 ` [mm-unstable v4 1/5] mm: memcg: change flush_next_time to flush_last_time Yosry Ahmed
2023-11-29 3:21 ` [mm-unstable v4 2/5] mm: memcg: move vmstats structs definition above flushing code Yosry Ahmed
2023-11-29 3:21 ` [mm-unstable v4 3/5] mm: memcg: make stats flushing threshold per-memcg Yosry Ahmed
2023-12-02 7:48 ` Shakeel Butt
2023-11-29 3:21 ` [mm-unstable v4 4/5] mm: workingset: move the stats flush into workingset_test_recent() Yosry Ahmed
2023-12-02 8:07 ` Shakeel Butt
2023-11-29 3:21 ` [mm-unstable v4 5/5] mm: memcg: restore subtree stats flushing Yosry Ahmed
2023-12-02 1:57 ` Bagas Sanjaya
2023-12-02 2:56 ` Waiman Long
2023-12-02 5:53 ` Bagas Sanjaya
2023-12-04 19:51 ` Yosry Ahmed
2023-12-02 8:31 ` Shakeel Butt
2023-12-04 20:12 ` Yosry Ahmed
2023-12-04 21:37 ` Yosry Ahmed
2023-12-04 23:31 ` Shakeel Butt
2023-12-04 23:46 ` Wei Xu
2023-12-04 23:49 ` Yosry Ahmed
2023-12-04 23:58 ` Shakeel Butt
2023-12-12 18:43 ` Andrew Morton
2023-12-12 19:11 ` Shakeel Butt
2023-12-12 20:44 ` Yosry Ahmed
2023-12-02 4:51 ` [mm-unstable v4 0/5] mm: memcg: subtree stats flushing and thresholds Bagas Sanjaya
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=20231129032154.3710765-1-yosryahmed@google.com \
--to=yosryahmed@google.com \
--cc=akpm@linux-foundation.org \
--cc=cerasuolodomenico@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=ivan@cloudflare.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=tj@kernel.org \
--cc=weixugc@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