From: Masayoshi Mizuma <msys.mizuma@gmail.com>
To: Shakeel Butt <shakeelb@google.com>
Cc: Roman Gushchin <guro@fb.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Cgroups <cgroups@vger.kernel.org>, Linux MM <linux-mm@kvack.org>
Subject: Re: memcg: performance degradation since v5.9
Date: Mon, 12 Apr 2021 11:22:10 -0400 [thread overview]
Message-ID: <20210412152210.y5bizdfbn62sgeqg@gabell> (raw)
In-Reply-To: <CALvZod4uRU==p7Z0eP_xO49iA3ShFDHKzyWZbd7RdMso5PHsfA@mail.gmail.com>
On Fri, Apr 09, 2021 at 09:50:45AM -0700, Shakeel Butt wrote:
> On Fri, Apr 9, 2021 at 9:35 AM Masayoshi Mizuma <msys.mizuma@gmail.com> wrote:
> >
> [...]
> > > Can you please explain how to read these numbers? Or at least put a %
> > > regression.
> >
> > Let me summarize them here.
> > The total duration ('total' column above) of each system call is as follows
> > if v5.8 is assumed as 100%:
> >
> > - sendto:
> > - v5.8 100%
> > - v5.9 128%
> > - v5.12-rc6 116%
> >
> > - revfrom:
> > - v5.8 100%
> > - v5.9 114%
> > - v5.12-rc6 108%
> >
>
> Thanks, that is helpful. Most probably the improvement of 5.12 from
> 5.9 is due to 3de7d4f25a7438f ("mm: memcg/slab: optimize objcg stock
> draining").
>
> [...]
> > >
> > > One idea would be to increase MEMCG_CHARGE_BATCH.
> >
> > Thank you for the idea! It's hard-corded as 32 now, so I'm wondering it may be
> > a good idea to make MEMCG_CHARGE_BATCH tunable from a kernel parameter or something.
> >
>
Hi!
Thank you for your comments!
> Can you rerun the benchmark with MEMCG_CHARGE_BATCH equal 64UL?
Yes, I reran the benchmark with MEMCG_CHARGE_BATCH == 64UL, but it seems that
it doesn't reduce the duration of system calls...
- v5.12-rc6 vanilla
syscall total
(msec)
--------- --------
sendto 3049.221
recvfrom 2421.601
- v5.12-rc6 with MEMCG_CHARGE_BATCH==64
syscall total
(msec)
--------- --------
sendto 3071.607
recvfrom 2436.488
> I think with memcg stats moving to rstat, the stat accuracy is not an
> issue if we increase MEMCG_CHARGE_BATCH to 64UL. Not sure if we want
> this to be tuneable but most probably we do want this to be sync'ed
> with SWAP_CLUSTER_MAX.
Thanks. I understand that.
Waiman posted some patches to reduce the overhead [1]. I'll try the patch.
[1]: https://lore.kernel.org/linux-mm/51ea6b09-b7ee-36e9-a500-b7141bd3a42b@redhat.com/T/#me75806a3555e7a42e793f099b98c42e687962d10
Thanks!
Masa
next prev parent reply other threads:[~2021-04-12 15:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 19:39 memcg: performance degradation since v5.9 Masayoshi Mizuma
2021-04-08 20:53 ` Roman Gushchin
2021-04-08 21:08 ` Shakeel Butt
2021-04-09 16:35 ` Masayoshi Mizuma
2021-04-09 16:50 ` Shakeel Butt
2021-04-12 15:22 ` Masayoshi Mizuma [this message]
2021-04-09 16:05 ` Masayoshi Mizuma
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=20210412152210.y5bizdfbn62sgeqg@gabell \
--to=msys.mizuma@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=shakeelb@google.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;
as well as URLs for NNTP newsgroup(s).