> -----Original Message-----
> From: Shakeel Butt <shakeelb@xxxxxxxxxx>
> Sent: Thursday, May 11, 2023 3:00 AM
> To: Zhang, Cathy <cathy.zhang@xxxxxxxxx>
> Cc: Eric Dumazet <edumazet@xxxxxxxxxx>; Linux MM <linux-
> mm@xxxxxxxxx>; Cgroups <cgroups@xxxxxxxxxxxxxxx>; Paolo Abeni
> <pabeni@xxxxxxxxxx>; davem@xxxxxxxxxxxxx; kuba@xxxxxxxxxx;
> Brandeburg, Jesse <jesse.brandeburg@xxxxxxxxx>; Srinivas, Suresh
> <suresh.srinivas@xxxxxxxxx>; Chen, Tim C <tim.c.chen@xxxxxxxxx>; You,
> Lizhen <lizhen.you@xxxxxxxxx>; eric.dumazet@xxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH net-next 1/2] net: Keep sk->sk_forward_alloc as a proper
> size
>
> On Wed, May 10, 2023 at 9:09 AM Zhang, Cathy <cathy.zhang@xxxxxxxxx>
> wrote:
> >
> >
> [...]
> > > > >
> > > > > Have you tried to increase batch sizes ?
> > > >
> > > > I jus picked up 256 and 1024 for a try, but no help, the overhead still
> exists.
> > >
> > > This makes no sense at all.
> >
> > Eric,
> >
> > I added a pr_info in try_charge_memcg() to print nr_pages if nr_pages
> > >= MEMCG_CHARGE_BATCH, except it prints 64 during the initialization
> > of instances, there is no other output during the running. That means
> > nr_pages is not over 64, I guess that might be the reason why to
> > increase MEMCG_CHARGE_BATCH doesn't affect this case.
> >
>
> I am assuming you increased MEMCG_CHARGE_BATCH to 256 and 1024 but
> that did not help. To me that just means there is a different bottleneck in the
> memcg charging codepath. Can you please share the perf profile? Please
> note that memcg charging does a lot of other things as well like updating
> memcg stats and checking (and enforcing) memory.high even if you have not
> set memory.high.
Thanks Shakeel! I will check more details on what you mentioned. We use
"sudo perf top -p $(docker inspect -f '{{.State.Pid}}' memcached_2)" to monitor
one of those instances, and also use "sudo perf top" to check the overhead from
system wide.
