At the moment memcg stats are read in four contexts:
1. memcg stat user interfaces
2. dirty throttling
3. page fault
4. memory reclaim
Currently the kernel flushes the stats for first two cases. Flushing the
stats for remaining two casese may have performance impact. Always
flushing the memcg stats on the page fault code path may negatively
impacts the performance of the applications. In addition flushing in the
memory reclaim code path, though treated as slowpath, can become the
source of contention for the global lock taken for stat flushing because
when system or memcg is under memory pressure, many tasks may enter the
reclaim path.
Instead of synchronously flushing the stats, this patch adds support of
asynchronous periodic flushing of the memcg stats. For now the flushing
period is hardcoded to 2*HZ but that can be changed later through maybe
sysctl if need arise.
This patch does add the explicit flushing in the kswapd thread as the
number of kswapd threads which corresponds to the number of nodes on
realistic machines are usually low.
Signed-off-by: Shakeel Butt <[email protected]>
---
Changes since v1:
- use system_unbound_wq for flushing the memcg stats
include/linux/memcontrol.h | 10 ++++++++++
mm/memcontrol.c | 14 ++++++++++++++
mm/vmscan.c | 6 ++++++
3 files changed, 30 insertions(+)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 0bfa0409af22..f34214382a1c 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -991,6 +991,12 @@ static inline unsigned long lruvec_page_state_local(struct lruvec *lruvec,
return x;
}
+static inline void mem_cgroup_flush_stats(void)
+{
+ if (!mem_cgroup_disabled())
+ cgroup_rstat_flush(root_mem_cgroup->css.cgroup);
+}
+
void __mod_memcg_lruvec_state(struct lruvec *lruvec, enum node_stat_item idx,
int val);
void __mod_lruvec_kmem_state(void *p, enum node_stat_item idx, int val);
@@ -1400,6 +1406,10 @@ static inline unsigned long lruvec_page_state_local(struct lruvec *lruvec,
return node_page_state(lruvec_pgdat(lruvec), idx);
}
+static inline void mem_cgroup_flush_stats(void)
+{
+}
+
static inline void __mod_memcg_lruvec_state(struct lruvec *lruvec,
enum node_stat_item idx, int val)
{
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 6e24fd8c5301..5910658bac84 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -97,6 +97,10 @@ bool cgroup_memory_noswap __ro_after_init;
static DECLARE_WAIT_QUEUE_HEAD(memcg_cgwb_frn_waitq);
#endif
+/* Periodically flush memcg and lruvec stats. */
+static void flush_memcg_stats(struct work_struct *w);
+static DECLARE_DEFERRABLE_WORK(stats_flush, flush_memcg_stats);
+
/* Whether legacy memory+swap accounting is active */
static bool do_memsw_account(void)
{
@@ -5248,6 +5252,10 @@ static int mem_cgroup_css_online(struct cgroup_subsys_state *css)
/* Online state pins memcg ID, memcg ID pins CSS */
refcount_set(&memcg->id.ref, 1);
css_get(css);
+
+ if (unlikely(mem_cgroup_is_root(memcg)))
+ queue_delayed_work(system_unbound_wq, &stats_flush, 2UL*HZ);
+
return 0;
}
@@ -5339,6 +5347,12 @@ static void mem_cgroup_css_reset(struct cgroup_subsys_state *css)
memcg_wb_domain_size_changed(memcg);
}
+static void flush_memcg_stats(struct work_struct *w)
+{
+ cgroup_rstat_flush(root_mem_cgroup->css.cgroup);
+ queue_delayed_work(system_unbound_wq, &stats_flush, 2UL*HZ);
+}
+
static void mem_cgroup_css_rstat_flush(struct cgroup_subsys_state *css, int cpu)
{
struct mem_cgroup *memcg = mem_cgroup_from_css(css);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index a7602f71ec04..7bf9a4241dd9 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3893,6 +3893,12 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int highest_zoneidx)
sc.may_writepage = !laptop_mode && !nr_boost_reclaim;
sc.may_swap = !nr_boost_reclaim;
+ /*
+ * Flush the memory cgroup stats, so that we read accurate
+ * per-memcg lruvec stats for heuristics later.
+ */
+ mem_cgroup_flush_stats();
+
/*
* Do some background aging of the anon list, to give
* pages a chance to be referenced before reclaiming. All
--
2.32.0.272.g935e593368-goog
Hey Shakeel,
On Tue, Jun 15, 2021 at 10:44:35AM -0700, Shakeel Butt wrote:
> At the moment memcg stats are read in four contexts:
>
> 1. memcg stat user interfaces
> 2. dirty throttling
> 3. page fault
> 4. memory reclaim
>
> Currently the kernel flushes the stats for first two cases. Flushing the
> stats for remaining two casese may have performance impact. Always
> flushing the memcg stats on the page fault code path may negatively
> impacts the performance of the applications. In addition flushing in the
> memory reclaim code path, though treated as slowpath, can become the
> source of contention for the global lock taken for stat flushing because
> when system or memcg is under memory pressure, many tasks may enter the
> reclaim path.
>
> Instead of synchronously flushing the stats, this patch adds support of
> asynchronous periodic flushing of the memcg stats. For now the flushing
> period is hardcoded to 2*HZ but that can be changed later through maybe
> sysctl if need arise.
I'm concerned that quite a lot can happen in terms of reclaim and page
faults in 2 seconds. It's conceivable that the error of a fixed 2s
flush can actually exceed the error of a fixed percpu batch size.
The way the global vmstat implementation manages error is doing both:
ratelimiting and timelimiting. It uses percpu batching to limit the
error when it gets busy, and periodic flushing to limit the length of
time consumers of those stats could be stuck trying to reach a state
that the batching would otherwise prevent from being reflected.
Maybe we can use a combination of ratelimiting and timelimiting too?
We shouldn't flush on every fault, but what about a percpu ratelimit
that would at least bound the error to NR_CPU instead of nr_cgroups?
For thundering herds during reclaim: as long as they all tried to
flush from the root, only one of them would actually need to do the
work, and we could use trylock. If the lock is already taken, you can
move on knowing that somebody is already doing the shared flush work.
On Tue, Jun 15, 2021 at 12:29 PM Johannes Weiner <[email protected]> wrote:
>
> Hey Shakeel,
>
> On Tue, Jun 15, 2021 at 10:44:35AM -0700, Shakeel Butt wrote:
> > At the moment memcg stats are read in four contexts:
> >
> > 1. memcg stat user interfaces
> > 2. dirty throttling
> > 3. page fault
> > 4. memory reclaim
> >
> > Currently the kernel flushes the stats for first two cases. Flushing the
> > stats for remaining two casese may have performance impact. Always
> > flushing the memcg stats on the page fault code path may negatively
> > impacts the performance of the applications. In addition flushing in the
> > memory reclaim code path, though treated as slowpath, can become the
> > source of contention for the global lock taken for stat flushing because
> > when system or memcg is under memory pressure, many tasks may enter the
> > reclaim path.
> >
> > Instead of synchronously flushing the stats, this patch adds support of
> > asynchronous periodic flushing of the memcg stats. For now the flushing
> > period is hardcoded to 2*HZ but that can be changed later through maybe
> > sysctl if need arise.
>
> I'm concerned that quite a lot can happen in terms of reclaim and page
> faults in 2 seconds. It's conceivable that the error of a fixed 2s
> flush can actually exceed the error of a fixed percpu batch size.
>
Yes, that is possible.
> The way the global vmstat implementation manages error is doing both:
> ratelimiting and timelimiting. It uses percpu batching to limit the
> error when it gets busy, and periodic flushing to limit the length of
> time consumers of those stats could be stuck trying to reach a state
> that the batching would otherwise prevent from being reflected.
>
> Maybe we can use a combination of ratelimiting and timelimiting too?
>
> We shouldn't flush on every fault, but what about a percpu ratelimit
> that would at least bound the error to NR_CPU instead of nr_cgroups?
>
Couple questions here:
First, to convert the error bound to NR_CPU from nr_cgroups, I think
we have to move from (delta > threshold) comparison to
(num_update_events > threshold). Previously an increment event
followed by decrement would keep the delta to 0 (or same) but after
this change num_update_events would be 2. Is that ok?
Second, do we want to synchronously flush the stats when we cross the
threshold on update or asynchronously by queuing the flush with zero
delay?
> For thundering herds during reclaim: as long as they all tried to
> flush from the root, only one of them would actually need to do the
> work, and we could use trylock. If the lock is already taken, you can
> move on knowing that somebody is already doing the shared flush work.
Yes, this makes sense.
Hello Shakeel.
On Tue, Jun 15, 2021 at 10:44:35AM -0700, Shakeel Butt <[email protected]> wrote:
> At the moment memcg stats are read in four contexts:
>
> 1. memcg stat user interfaces
> 2. dirty throttling
> 3. page fault
> 4. memory reclaim
Sorry for being dense or ignorant -- what do you refer to with the point
no. 3 (memcg stats reader during page fault)?
Thanks,
Michal
On Thu, Jun 24, 2021 at 7:01 AM Michal Koutný <[email protected]> wrote:
>
> Hello Shakeel.
>
> On Tue, Jun 15, 2021 at 10:44:35AM -0700, Shakeel Butt <[email protected]> wrote:
> > At the moment memcg stats are read in four contexts:
> >
> > 1. memcg stat user interfaces
> > 2. dirty throttling
> > 3. page fault
> > 4. memory reclaim
>
> Sorry for being dense or ignorant -- what do you refer to with the point
> no. 3 (memcg stats reader during page fault)?
>
Yes, specifically workingset_refault() which reads lruvec stats
directly through lruvec_page_state and indirectly through
lru_note_cost_page.
Hey Shakeel,
Sorry about the delay.
On Tue, Jun 15, 2021 at 02:52:37PM -0700, Shakeel Butt wrote:
> On Tue, Jun 15, 2021 at 12:29 PM Johannes Weiner <[email protected]> wrote:
> > The way the global vmstat implementation manages error is doing both:
> > ratelimiting and timelimiting. It uses percpu batching to limit the
> > error when it gets busy, and periodic flushing to limit the length of
> > time consumers of those stats could be stuck trying to reach a state
> > that the batching would otherwise prevent from being reflected.
> >
> > Maybe we can use a combination of ratelimiting and timelimiting too?
> >
> > We shouldn't flush on every fault, but what about a percpu ratelimit
> > that would at least bound the error to NR_CPU instead of nr_cgroups?
> >
>
> Couple questions here:
>
> First, to convert the error bound to NR_CPU from nr_cgroups, I think
> we have to move from (delta > threshold) comparison to
> (num_update_events > threshold). Previously an increment event
> followed by decrement would keep the delta to 0 (or same) but after
> this change num_update_events would be 2. Is that ok?
Yeah, I think that's fine. Or at least I can't think of a real-world
application that would inc and dec the same counter over and over and
so would do much better with delta spilling over event ratelimiting.
And the ratelimiting should already ensure by itself that the cost is
at least acceptable when continuously updating and reading counters.
> Second, do we want to synchronously flush the stats when we cross the
> threshold on update or asynchronously by queuing the flush with zero
> delay?
I think flushing by worker is better because we can see updates from
all sorts of contexts with all sorts of locks held. That could make
for some difficult dependencies and latency sources when serializing
those on cgroup_rstat_lock.