Re: memcg: infrastructure to flush memcg stats

Re: memcg: infrastructure to flush memcg stats

[Linus Torvalds]

So the kernel test robot complained about this commit back when it was
in the -mm tree:

  https://lore.kernel.org/all/20210726022421.GB21872@xsang-OptiPlex-9020/

but I never really saw anything else about it, and left it alone.

However, now Michael Larabel (of phoronix) points to this commit too,
and says it regresses several of his benchmarks too.

Shakeel, are you looking at this? Based on previous experience,
Michael is great at running benchmarks on patches that you come up
with.

           Linus

On Thu, Sep 16, 2021 at 2:55 AM Michael Larabel
<Michael@michaellarabel.com> wrote:
>
> Are you still looking at aa48e47e3906 around performance regressions[1]?
>
> With 5.15-rc1 on multiple systems I am seeing timed software compilation
> tests regressing compared to 5.14. A variety of different software
> builds are all slowing down by several percent when running on a 5.15
> kernel. The bisect led back to aa48e47e3906 as the first bad commit. I
> can't seem to find any discussions around that patch in more recent days
> so figured I'd ping you in case something was missed.
>
> Thanks,
>
> Michael
>
> [1]
> https://lists.01.org/hyperkitty/list/lkp@lists.01.org/message/MS2J5FCYQD62W4E5LHHPWC7YH7TWKUSV/
>

Re: memcg: infrastructure to flush memcg stats

[Shakeel Butt]

On Thu, Sep 16, 2021 at 1:45 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So the kernel test robot complained about this commit back when it was
> in the -mm tree:
>
>   https://lore.kernel.org/all/20210726022421.GB21872@xsang-OptiPlex-9020/
>
> but I never really saw anything else about it, and left it alone.
>
> However, now Michael Larabel (of phoronix) points to this commit too,
> and says it regresses several of his benchmarks too.
>
> Shakeel, are you looking at this? Based on previous experience,
> Michael is great at running benchmarks on patches that you come up
> with.
>

Yes, I am actively looking into this and the discussion is happening
at https://lore.kernel.org/all/20210905124439.GA15026@xsang-OptiPlex-9020/T/#u

I would definitely take up with Michael on helping with running the benchmarks.

We know the source of the regression which is queue_work() in
__mod_memcg_lruvec_state(). Previously we were doing atomic addition
up the memcg tree. I have to come up with an approach to reduce the
calls to queue_work() in that path.

thanks,
Shakeel