Re: [PATCH 3/4] mm/memcg: Add a local_lock_t for IRQ and TASK object.

[Michal Hocko <mhocko@suse.com>]

On Tue 08-02-22 18:17:35, Sebastian Andrzej Siewior wrote:
> On 2022-02-03 17:01:41 [+0100], Vlastimil Babka wrote:
> > > Let me know if a revert is preferred or you want to keep that so that I
> > 
> > I see that's discussed in the subthread with Michal Hocko, so I would be
> > also leaning towards revert unless convincing numbers are provided.
> > 
> > > can prepare the patches accordingly before posting.
> > 
> > An acceptable form of this would have to basically replace the bool
> > stock_lock_acquried with two variants of the code paths that rely on it,
> > feel free to read though the previous occurence :)
> > https://lore.kernel.org/all/CAHk-=wiJLqL2cUhJbvpyPQpkbVOu1rVSzgO2=S2jC55hneLtfQ@mail.gmail.com/
> 
> I did that locally already. I was referring to the revert.
> So repost with bool fixed and the revert will be discussed later or
> include the revert at the begin of the series and then rebase these
> patches on top of it? I probably don't get to it before FRI so I don't
> try to rush anyone here ;)

If you start with the revert then you should be able to get rid of a lot
of complexity, right? We still haven't heard from Weiman about his
original optimization reasoning. There might be good reasons for it
which just hasn't been explicitly mentioned yet.

As already said, if the optimization is visible only in microbenchmarks
without any real workload benefiting from it I would rather consider
reverting it and make the RT addoption easier. Micro optimizations can
always be done on top.
-- 
Michal Hocko
SUSE Labs