From: Shakeel Butt <shakeelb@google.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Cgroups <cgroups@vger.kernel.org>, Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] memcg: unify memcg stat flushing
Date: Wed, 13 Oct 2021 12:24:31 -0700 [thread overview]
Message-ID: <CALvZod6dN5Ub-r9+evXYCaeNuzrDs1byPLY1DAyn=R7rqHoqKg@mail.gmail.com> (raw)
In-Reply-To: <20211013180122.GA1007@blackbody.suse.cz>
On Wed, Oct 13, 2021 at 11:01 AM Michal Koutný <mkoutny@suse.com> wrote:
>
> Hello Shakeel.
>
> (Sorry for taking so long getting down to this.)
>
> On Fri, Oct 01, 2021 at 12:00:40PM -0700, Shakeel Butt <shakeelb@google.com> wrote:
> > There is no need for that. We just need one flusher and everyone else
> > can benefit.
>
> I imagine a cgroup with an intricate deep hiearchy with many updates and
> a separate (simpler) sibling/independent cgroup that would need to pay
> the costs of the first hierarchy updates [1] when it asks just for its
> own stats (bound by the amount that's leftover from the periodic
> updates).
>
> The stats files (or wb stats) are likely not that time sensitive and the
> reclaim (that can be local only but is slow path anyway) already uses
> the global flushing.
>
> I wonder whether the bigger benefit would be to retain the global
> stats_flush_threshold counter but flush only local subtree.
I did contemplate on this (i.e. a stat read paying the flushing price
for everyone else) but decided to keep as is based on:
1) The periodic async flush will keep the update tree small and will
keep infrequent readers cheap.
2) Keep things simple for now and come back if someone complains for
very frequent stats readers.
Shakeel
WARNING: multiple messages have this Message-ID (diff)
From: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
To: "Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org>
Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2 2/2] memcg: unify memcg stat flushing
Date: Wed, 13 Oct 2021 12:24:31 -0700 [thread overview]
Message-ID: <CALvZod6dN5Ub-r9+evXYCaeNuzrDs1byPLY1DAyn=R7rqHoqKg@mail.gmail.com> (raw)
In-Reply-To: <20211013180122.GA1007-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
On Wed, Oct 13, 2021 at 11:01 AM Michal Koutn√Ω <mkoutny-IBi9RG/b67k@public.gmane.org> wrote:
>
> Hello Shakeel.
>
> (Sorry for taking so long getting down to this.)
>
> On Fri, Oct 01, 2021 at 12:00:40PM -0700, Shakeel Butt <shakeelb@google.com> wrote:
> > There is no need for that. We just need one flusher and everyone else
> > can benefit.
>
> I imagine a cgroup with an intricate deep hiearchy with many updates and
> a separate (simpler) sibling/independent cgroup that would need to pay
> the costs of the first hierarchy updates [1] when it asks just for its
> own stats (bound by the amount that's leftover from the periodic
> updates).
>
> The stats files (or wb stats) are likely not that time sensitive and the
> reclaim (that can be local only but is slow path anyway) already uses
> the global flushing.
>
> I wonder whether the bigger benefit would be to retain the global
> stats_flush_threshold counter but flush only local subtree.
I did contemplate on this (i.e. a stat read paying the flushing price
for everyone else) but decided to keep as is based on:
1) The periodic async flush will keep the update tree small and will
keep infrequent readers cheap.
2) Keep things simple for now and come back if someone complains for
very frequent stats readers.
Shakeel
next prev parent reply other threads:[~2021-10-13 19:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 19:00 [PATCH v2 1/2] memcg: flush stats only if updated Shakeel Butt
2021-10-01 19:00 ` Shakeel Butt
2021-10-01 19:00 ` [PATCH v2 2/2] memcg: unify memcg stat flushing Shakeel Butt
2021-10-01 19:00 ` Shakeel Butt
2021-10-13 18:01 ` Michal Koutný
2021-10-13 18:01 ` Michal Koutný
2021-10-13 19:24 ` Shakeel Butt [this message]
2021-10-13 19:24 ` Shakeel Butt
2021-10-14 9:04 ` Michal Koutný
2021-10-14 9:04 ` Michal Koutný
2021-10-13 18:01 ` [PATCH v2 1/2] memcg: flush stats only if updated Michal Koutný
2021-10-13 18:01 ` Michal Koutný
2021-10-14 16:31 ` Shakeel Butt
2021-10-14 16:31 ` Shakeel Butt
2021-10-15 17:55 ` Michal Koutný
2021-10-15 17:55 ` Michal Koutný
2021-11-04 21:27 ` Andrew Morton
2021-11-04 21:27 ` Andrew Morton
2021-11-04 22:09 ` Shakeel Butt
2021-11-04 22:09 ` Shakeel Butt
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='CALvZod6dN5Ub-r9+evXYCaeNuzrDs1byPLY1DAyn=R7rqHoqKg@mail.gmail.com' \
--to=shakeelb@google.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.