lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgW3dYJyh6S_U5ot_0Q-OU0-vrS=L8Uky4+Y5fZXeLcKw@mail.gmail.com>
Date:   Tue, 7 Sep 2021 10:52:17 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Shakeel Butt <shakeelb@...gle.com>,
        Minchan Kim <minchan@...nel.org>
Cc:     Jens Axboe <axboe@...nel.dk>,
        kernel test robot <oliver.sang@...el.com>,
        Vasily Averin <vvs@...tuozzo.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Andrei Vagin <avagin@...il.com>,
        Borislav Petkov <bp@...en8.de>, Borislav Petkov <bp@...e.de>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        Jeff Layton <jlayton@...nel.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Michal Hocko <mhocko@...nel.org>,
        Oleg Nesterov <oleg@...hat.com>, Roman Gushchin <guro@...com>,
        Serge Hallyn <serge@...lyn.com>, Tejun Heo <tj@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Yutian Yang <nglaive@...il.com>,
        Zefan Li <lizefan.x@...edance.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
        kernel test robot <lkp@...el.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        Feng Tang <feng.tang@...el.com>,
        Zhengjun Xing <zhengjun.xing@...ux.intel.com>
Subject: Re: [memcg] 0f12156dff: will-it-scale.per_process_ops -33.6% regression

On Tue, Sep 7, 2021 at 9:49 AM Shakeel Butt <shakeelb@...gle.com> wrote:
>
> On Tue, Sep 7, 2021 at 9:40 AM Linus Torvalds
> <torvalds@...ux-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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ