Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210907150757.GE17617@xsang-OptiPlex-9020> <dbc9955d-6c28-1dd5-b842-ef39a762aa3b@kernel.dk>
 <CAHk-=wgrF65BpP6P6_a6+k+C8V+JOBiEx0X-c9idiM87uk32FQ@mail.gmail.com> <CALvZod5Q_K=xLpBWTLgg38X_w23HVSyqW2_Jnz7p=JR+kDD_-w@mail.gmail.com>
In-Reply-To: <CALvZod5Q_K=xLpBWTLgg38X_w23HVSyqW2_Jnz7p=JR+kDD_-w@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 7 Sep 2021 10:52:17 -0700
Message-ID: <CAHk-=wgW3dYJyh6S_U5ot_0Q-OU0-vrS=L8Uky4+Y5fZXeLcKw@mail.gmail.com>
Subject: Re: [memcg] 0f12156dff: will-it-scale.per_process_ops -33.6% regression
To:     Shakeel Butt <shakeelb@google.com>,
        Minchan Kim <minchan@kernel.org>
Cc:     Jens Axboe <axboe@kernel.dk>,
        kernel test robot <oliver.sang@intel.com>,
        Vasily Averin <vvs@virtuozzo.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Alexey Dobriyan <adobriyan@gmail.com>,
        Andrei Vagin <avagin@gmail.com>,
        Borislav Petkov <bp@alien8.de>, Borislav Petkov <bp@suse.de>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Dmitry Safonov <0x7f454c46@gmail.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        "J. Bruce Fields" <bfields@fieldses.org>,
        Jeff Layton <jlayton@kernel.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Kirill Tkhai <ktkhai@virtuozzo.com>,
        Michal Hocko <mhocko@kernel.org>,
        Oleg Nesterov <oleg@redhat.com>, Roman Gushchin <guro@fb.com>,
        Serge Hallyn <serge@hallyn.com>, Tejun Heo <tj@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vladimir Davydov <vdavydov.dev@gmail.com>,
        Yutian Yang <nglaive@gmail.com>,
        Zefan Li <lizefan.x@bytedance.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>, lkp@lists.01.org,
        kernel test robot <lkp@intel.com>,
        "Huang, Ying" <ying.huang@intel.com>,
        Feng Tang <feng.tang@intel.com>,
        Zhengjun Xing <zhengjun.xing@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Sep 7, 2021 at 9:49 AM Shakeel Butt <shakeelb@google.com> wrote:
>
> On Tue, Sep 7, 2021 at 9:40 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > We are worried about them. I'm considering reverting several of them
> > because I think the problems are
> >
> >  (a) big
> >
> >  (b) nontrivial
> >
> > and the patches clearly weren't ready and people weren't aware of this issue.
>
> Sounds good to me. Please let me know which patches you are planning
> to revert. I will work on the followup to make those acceptable.

The one that looks clear-cut is the one in this thread:

    0f12156dff28 memcg: enable accounting for file lock caches

which seems to result in regressions on multiple machines and just be
very bad for anything that uses file locking. I'm not entirely sure
how much that would show up in real life, but I can most definitely
imagine it being a problem on a real load.

There's a few other regression reports I've seen, like

    5387c90490f7 mm/memcg: improve refill_obj_stock() performance

but that one had mixed reports (it improved another benchmark), and it
looks like Minchan has a fix for the regression already.

And

    aa48e47e3906 memcg: infrastructure to flush memcg stats
    b65584344415 memcg: enable accounting for pollfd and select bits arrays

were reported as a regression in -mm, but not in mainline yet.

I assume (but didn't check) that aa48e47e3906 is a bigger deal to revert.

So _right_now_ my plan is to revert the two obvious cases:

    0f12156dff28 memcg: enable accounting for file lock caches
    b65584344415 memcg: enable accounting for pollfd and select bits arrays

on the assumption that the memcg accounting code needs some work to
make it less of a performance hog.

Does anybody have other commits they want to highlight (or other
comments) about this?

              Linus