From: Yang Shi <shy828301@gmail.com>
To: Roman Gushchin <guro@fb.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>,
Shakeel Butt <shakeelb@google.com>,
Dave Chinner <david@fromorbit.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux MM <linux-mm@kvack.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/9] mm: memcontrol: add per memcg shrinker nr_deferred
Date: Thu, 3 Dec 2020 16:22:52 -0800 [thread overview]
Message-ID: <CAHbLzkowkLEfBp=dXcnX9_w87E5ZifRW9af+s8DGaXDkM8__PQ@mail.gmail.com> (raw)
In-Reply-To: <20201203233055.GA1669930@carbon.DHCP.thefacebook.com>
On Thu, Dec 3, 2020 at 3:31 PM Roman Gushchin <guro@fb.com> wrote:
>
> On Thu, Dec 03, 2020 at 02:49:00PM -0800, Yang Shi wrote:
> > On Thu, Dec 3, 2020 at 12:07 PM Roman Gushchin <guro@fb.com> wrote:
> > >
> > > On Thu, Dec 03, 2020 at 10:03:44AM -0800, Yang Shi wrote:
> > > > On Wed, Dec 2, 2020 at 8:54 PM Yang Shi <shy828301@gmail.com> wrote:
> > > > >
> > > > > On Wed, Dec 2, 2020 at 7:06 PM Roman Gushchin <guro@fb.com> wrote:
> > > > > >
> > > > > > On Wed, Dec 02, 2020 at 10:27:21AM -0800, Yang Shi wrote:
> > > > > > > Currently the number of deferred objects are per shrinker, but some slabs, for example,
> > > > > > > vfs inode/dentry cache are per memcg, this would result in poor isolation among memcgs.
> > > > > > >
> > > > > > > The deferred objects typically are generated by __GFP_NOFS allocations, one memcg with
> > > > > > > excessive __GFP_NOFS allocations may blow up deferred objects, then other innocent memcgs
> > > > > > > may suffer from over shrink, excessive reclaim latency, etc.
> > > > > > >
> > > > > > > For example, two workloads run in memcgA and memcgB respectively, workload in B is vfs
> > > > > > > heavy workload. Workload in A generates excessive deferred objects, then B's vfs cache
> > > > > > > might be hit heavily (drop half of caches) by B's limit reclaim or global reclaim.
> > > > > > >
> > > > > > > We observed this hit in our production environment which was running vfs heavy workload
> > > > > > > shown as the below tracing log:
> > > > > > >
> > > > > > > <...>-409454 [016] .... 28286961.747146: mm_shrink_slab_start: super_cache_scan+0x0/0x1a0 ffff9a83046f3458:
> > > > > > > nid: 1 objects to shrink 3641681686040 gfp_flags GFP_HIGHUSER_MOVABLE|__GFP_ZERO pgs_scanned 1 lru_pgs 15721
> > > > > > > cache items 246404277 delta 31345 total_scan 123202138
> > > > > > > <...>-409454 [022] .... 28287105.928018: mm_shrink_slab_end: super_cache_scan+0x0/0x1a0 ffff9a83046f3458:
> > > > > > > nid: 1 unused scan count 3641681686040 new scan count 3641798379189 total_scan 602
> > > > > > > last shrinker return val 123186855
> > > > > > >
> > > > > > > The vfs cache and page cache ration was 10:1 on this machine, and half of caches were dropped.
> > > > > > > This also resulted in significant amount of page caches were dropped due to inodes eviction.
> > > > > > >
> > > > > > > Make nr_deferred per memcg for memcg aware shrinkers would solve the unfairness and bring
> > > > > > > better isolation.
> > > > > > >
> > > > > > > When memcg is not enabled (!CONFIG_MEMCG or memcg disabled), the shrinker's nr_deferred
> > > > > > > would be used. And non memcg aware shrinkers use shrinker's nr_deferred all the time.
> > > > > > >
> > > > > > > Signed-off-by: Yang Shi <shy828301@gmail.com>
> > > > > > > ---
> > > > > > > include/linux/memcontrol.h | 9 +++
> > > > > > > mm/memcontrol.c | 112 ++++++++++++++++++++++++++++++++++++-
> > > > > > > mm/vmscan.c | 4 ++
> > > > > > > 3 files changed, 123 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > > > > > > index 922a7f600465..1b343b268359 100644
> > > > > > > --- a/include/linux/memcontrol.h
> > > > > > > +++ b/include/linux/memcontrol.h
> > > > > > > @@ -92,6 +92,13 @@ struct lruvec_stat {
> > > > > > > long count[NR_VM_NODE_STAT_ITEMS];
> > > > > > > };
> > > > > > >
> > > > > > > +
> > > > > > > +/* Shrinker::id indexed nr_deferred of memcg-aware shrinkers. */
> > > > > > > +struct memcg_shrinker_deferred {
> > > > > > > + struct rcu_head rcu;
> > > > > > > + atomic_long_t nr_deferred[];
> > > > > > > +};
> > > > > >
> > > > > > The idea makes total sense to me. But I wonder if we can add nr_deferred to
> > > > > > struct list_lru_one, instead of adding another per-memcg per-shrinker entity?
> > > > > > I guess it can simplify the code quite a lot. What do you think?
> > > > >
> > > > > Aha, actually this exactly was what I did at the first place. But Dave
> > > > > NAK'ed this approach. You can find the discussion at:
> > > > > https://lore.kernel.org/linux-mm/20200930073152.GH12096@dread.disaster.area/.
> > >
> > > Yes, this makes sense for me. Thank you for the link!
> > >
> > > >
> > > > I did prototypes for both approaches (move nr_deferred to list_lru or
> > > > to memcg). I preferred the list_lru approach at the first place. But
> > > > Dave's opinion does make perfect sense to me. So I dropped that
> > > > list_lru one. That email elaborated why moving nr_deferred to list_lru
> > > > is not appropriate.
> > >
> > > Hm, shouldn't we move list_lru to memcg then? It's not directly related
> > > to your patchset, but maybe it's something we should consider in the future.
> >
> > I haven't thought about this yet. I agree we could look into it
> > further later on.
> >
> > >
> > > What worries me is that with your patchset we'll have 3 separate
> > > per-memcg (per-node) per-shrinker entity, each with slightly different
> > > approach to allocate/extend/reparent/release. So it begs for some
> > > unification. I don't think it's a showstopper for your work though, it
> > > can be done later.
> >
> > Off the top of my head, we may be able to have shrinker_info struct,
> > it should look like:
> >
> > struct shrinker_info {
> > atomic_long_t nr_deferred;
> > /* Just one bit is used now */
> > u8 map:1;
> > }
> >
> > struct memcg_shrinker_info {
> > struct rcu_head rcu;
> > /* Indexed by shrinker ID */
> > struct shrinker_info info[];
> > }
> >
> > Then in struct mem_cgroup_per_node, we could have:
> >
> > struct mem_cgroup_per_node {
> > ....
> > struct memcg_shrinker_info __rcu *shrinker_info;
> > ....
> > }
> >
> > In this way shrinker_info should be allocated to all memcgs, including
> > root. But shrinker could ignore root's map bit. We may waste a little
> > bit memory, but we get unification.
> >
> > Would that work?
>
> Hm, not exactly, then you'll an ability to iterate with
> for_each_set_bit(i, map->map, shrinker_nr_max)...
Instead we could just iterate each shrinker_info struct to check if
its map is set.
> But you can probably do something like:
>
> struct shrinker_info {
> atomic_long_t nr_deferred;
>
> struct list_lru_one[]; /* optional, depends on the shrinker implementation */
> };
>
> struct memcg_shrinker_info {
> /* Indexed by shrinker ID */
> unsigned long *map[];
> struct shrinker_info *shrinker_info[];
Both map and shrinker_info has to be extendable, so they have to be
struct with rcu_head. So actually it is the same with separate
shrinker_map and shrinker_deferred, but under one struct. Actually I
tried this in my prototype, but I gave up it since it didn't simplify
the code IMHO.
> }
>
> Then you'll be able to allocate individual shrinker_info structures on-demand.
>
> But, please, take this all with a grain of salt, I didn't check if it's all really
> possible or there are some obstacles.
Thanks a lot for all the kind suggestions. I'd agree with you we could
revisit the unification later on. It seems there is not a simple and
straightforward way to unify them at the first glance. There might be
more evils in the detail.
>
> Thanks!
next prev parent reply other threads:[~2020-12-04 0:23 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 18:27 [RFC PATCH 0/9] Make shrinker's nr_deferred memcg aware Yang Shi
2020-12-02 18:27 ` [PATCH 1/9] mm: vmscan: simplify nr_deferred update code Yang Shi
2020-12-03 2:56 ` Roman Gushchin
2020-12-02 18:27 ` [PATCH 2/9] mm: vmscan: use nid from shrink_control for tracepoint Yang Shi
2020-12-03 3:13 ` Xiaqing (A)
2020-12-11 19:20 ` Yang Shi
2020-12-02 18:27 ` [PATCH 3/9] mm: memcontrol: rename memcg_shrinker_map_mutex to memcg_shrinker_mutex Yang Shi
2020-12-02 18:27 ` [PATCH 4/9] mm: vmscan: use a new flag to indicate shrinker is registered Yang Shi
2020-12-03 3:01 ` Roman Gushchin
2020-12-03 4:59 ` Yang Shi
2020-12-03 20:08 ` Roman Gushchin
2020-12-03 22:25 ` Yang Shi
2020-12-04 18:52 ` Johannes Weiner
2020-12-04 21:24 ` Yang Shi
2020-12-02 18:27 ` [PATCH 5/9] mm: memcontrol: add per memcg shrinker nr_deferred Yang Shi
2020-12-03 3:06 ` Roman Gushchin
2020-12-03 4:54 ` Yang Shi
2020-12-03 18:03 ` Yang Shi
2020-12-03 20:07 ` Roman Gushchin
2020-12-03 22:49 ` Yang Shi
2020-12-03 23:30 ` Roman Gushchin
2020-12-04 0:22 ` Yang Shi [this message]
2020-12-10 15:33 ` Johannes Weiner
2020-12-10 19:12 ` Yang Shi
2020-12-11 17:52 ` Yang Shi
2020-12-10 21:59 ` Yang Shi
2020-12-02 18:27 ` [PATCH 6/9] mm: vmscan: use per memcg nr_deferred of shrinker Yang Shi
2020-12-03 3:08 ` Roman Gushchin
2020-12-03 5:01 ` Yang Shi
2020-12-03 11:40 ` Kirill Tkhai
2020-12-08 17:13 ` Yang Shi
2020-12-09 15:41 ` Kirill Tkhai
2020-12-09 17:32 ` Yang Shi
2020-12-10 15:13 ` Johannes Weiner
2020-12-10 15:17 ` Kirill Tkhai
2020-12-15 16:44 ` Johannes Weiner
2020-12-02 18:27 ` [PATCH 7/9] mm: vmscan: don't need allocate shrinker->nr_deferred for memcg aware shrinkers Yang Shi
2020-12-02 18:27 ` [PATCH 8/9] mm: memcontrol: reparent nr_deferred when memcg offline Yang Shi
2020-12-02 18:27 ` [PATCH 9/9] mm: vmscan: shrink deferred objects proportional to priority Yang Shi
2020-12-03 2:52 ` [RFC PATCH 0/9] Make shrinker's nr_deferred memcg aware Roman Gushchin
2020-12-03 17:52 ` Yang Shi
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='CAHbLzkowkLEfBp=dXcnX9_w87E5ZifRW9af+s8DGaXDkM8__PQ@mail.gmail.com' \
--to=shy828301@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=ktkhai@virtuozzo.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=shakeelb@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).