Re: memcg: infrastructure to flush memcg stats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 16, 2021 at 1:45 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux