From: Michal Hocko <mhocko@suse.com>
To: Shakeel Butt <shakeelb@google.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Waiman Long <longman@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Muchun Song <songmuchun@bytedance.com>
Subject: Re: [PATCH v2] mm/list_lru: Fix possible race in memcg_reparent_list_lru_node()
Date: Thu, 31 Mar 2022 09:46:52 +0200 [thread overview]
Message-ID: <YkVcbElWjomA7ofF@dhcp22.suse.cz> (raw)
In-Reply-To: <20220331063956.5uqnab64cqnmcwyr@google.com>
On Thu 31-03-22 06:39:56, Shakeel Butt wrote:
> On Wed, Mar 30, 2022 at 07:48:45PM -0700, Roman Gushchin wrote:
> >
> >
> [...]
> >
> >
> > But honestly, I’d drop the original optimization together with
> > the fix, if only there is no _real world_ data on the problem and
> > the improvement. It seems like it has started as a nice simple
> > improvement, but the race makes it complex and probably not worth
> > the added complexity and fragility.
>
> I agree with dropping the original optimization as it is not really
> fixing an observed issue which may justify adding some complexity.
Completely agreed. The patch as it is proposed is not really acceptable
IMHO and I have to say I am worried that this is not the first time we
are in a situation when a follow up fixes or unrelated patches are
growing in complexity to fit on top of a performance optimizations which
do not refer to any actual numbers.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-03-31 7:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 17:26 [PATCH v2] mm/list_lru: Fix possible race in memcg_reparent_list_lru_node() Waiman Long
2022-03-30 19:46 ` Roman Gushchin
2022-03-31 2:14 ` Andrew Morton
2022-03-31 2:48 ` Roman Gushchin
2022-03-31 6:39 ` Shakeel Butt
2022-03-31 7:46 ` Michal Hocko [this message]
2022-04-01 1:11 ` Andrew Morton
2022-04-01 4:23 ` Shakeel Butt
2022-04-01 4:30 ` Muchun Song
2022-04-01 11:28 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YkVcbElWjomA7ofF@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=songmuchun@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.