From: Andrew Morton <akpm@linux-foundation.org>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Yafang Shao <shaoyafang@didiglobal.com>
Subject: Re: [PATCH v2] mm/memcontrol: keep local VM counters in sync with the hierarchical ones
Date: Thu, 11 Jul 2019 16:42:15 -0700 [thread overview]
Message-ID: <20190711164215.7e8fdcf635ac29f2d2572438@linux-foundation.org> (raw)
In-Reply-To: <1562851979-10610-1-git-send-email-laoar.shao@gmail.com>
On Thu, 11 Jul 2019 09:32:59 -0400 Yafang Shao <laoar.shao@gmail.com> wrote:
> After commit 815744d75152 ("mm: memcontrol: don't batch updates of local VM stats and events"),
> the local VM counters is not in sync with the hierarchical ones.
>
> Bellow is one example in a leaf memcg on my server (with 8 CPUs),
> inactive_file 3567570944
> total_inactive_file 3568029696
> We can find that the deviation is very great, that is because the 'val' in
> __mod_memcg_state() is in pages while the effective value in
> memcg_stat_show() is in bytes.
> So the maximum of this deviation between local VM stats and total VM
> stats can be (32 * number_of_cpu * PAGE_SIZE), that may be an unacceptable
> great value.
>
> We should keep the local VM stats in sync with the total stats.
> In order to keep this behavior the same across counters, this patch updates
> __mod_lruvec_state() and __count_memcg_events() as well.
hm.
So the local counters are presently more accurate than the hierarchical
ones because the hierarchical counters use batching. And the proposal
is to make the local counters less accurate so that the inaccuracies
will match.
It is a bit counter intuitive to hear than worsened accuracy is a good
thing! We're told that the difference may be "unacceptably great" but
we aren't told why. Some additional information to support this
surprising assertion would be useful, please. What are the use-cases
which are harmed by this difference and how are they harmed?
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -691,12 +691,15 @@ void __mod_memcg_state(struct mem_cgroup *memcg, int idx, int val)
> if (mem_cgroup_disabled())
> return;
>
> - __this_cpu_add(memcg->vmstats_local->stat[idx], val);
> -
> x = val + __this_cpu_read(memcg->vmstats_percpu->stat[idx]);
> if (unlikely(abs(x) > MEMCG_CHARGE_BATCH)) {
> struct mem_cgroup *mi;
>
> + /*
> + * Batch local counters to keep them in sync with
> + * the hierarchical ones.
> + */
> + __this_cpu_add(memcg->vmstats_local->stat[idx], x);
Given that we are no longer batching updates to the local counters, I
wonder if it is still necessary to accumulate the counters on a per-cpu
basis. ie, can we now do
atomic_long_add(memcg->vmstats_local->stat[idx], x);
and remove the loop in memcg_events_local()?
next prev parent reply other threads:[~2019-07-11 23:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 13:32 [PATCH v2] mm/memcontrol: keep local VM counters in sync with the hierarchical ones Yafang Shao
2019-07-11 15:19 ` Johannes Weiner
2019-07-11 23:42 ` Andrew Morton [this message]
2019-07-12 1:47 ` Yafang Shao
2019-07-12 5:29 ` Michal Hocko
2019-07-12 6:12 ` Yafang Shao
2019-07-12 6:53 ` Michal Hocko
2019-07-12 7:14 ` Yafang Shao
2019-07-12 7:54 ` Michal Hocko
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=20190711164215.7e8fdcf635ac29f2d2572438@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=laoar.shao@gmail.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=shaoyafang@didiglobal.com \
--cc=vdavydov.dev@gmail.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