From: Michal Hocko <mhocko@suse.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Shakeel Butt <shakeelb@google.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: remove lock_page_memcg() from rmap
Date: Wed, 30 Nov 2022 13:50:39 +0100 [thread overview]
Message-ID: <Y4dRnxrVkdqLRi1v@dhcp22.suse.cz> (raw)
In-Reply-To: <Y4ZYsrXLBFDIxuoO@cmpxchg.org>
On Tue 29-11-22 14:08:34, Johannes Weiner wrote:
[...]
> Short of further restricting the pages that can be moved, I don't see
> how we can get rid of the cgroup locks in rmap after all. :(
:(
> We can try limiting move candidates to present ptes. But maybe it's
> indeed time to deprecate the legacy charge moving altogether, and get
> rid of the entire complication.
>
> Hugh, Shakeel, Michal, what do you think?
I do agree with Hugh that going part way will likely not solve the
general maintenance burden. I am OK with dropping the functionality but
we should at least add a big fat warning if anybody wants to enable
memory.move_charge_at_immigrate. If there are any workload which
absolutely depend on the feature (which would make them impossible to
migrate to v2 btw) then we want to hear about that and address in some
way.
An incremental deprecation by limiting to present ptes sounds like this
semantic change might get overlooked for an extended time.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2022-11-30 12:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 18:18 [PATCH] mm: remove lock_page_memcg() from rmap Johannes Weiner
2022-11-23 18:34 ` Shakeel Butt
2022-11-24 6:03 ` Hugh Dickins
2022-11-28 16:59 ` Johannes Weiner
2022-11-29 19:08 ` Johannes Weiner
2022-11-29 19:23 ` Linus Torvalds
2022-11-29 19:42 ` Shakeel Butt
2022-11-30 7:33 ` Hugh Dickins
2022-11-30 16:42 ` Shakeel Butt
2022-11-30 17:36 ` Hugh Dickins
2022-11-30 22:30 ` Johannes Weiner
2022-12-01 0:13 ` Hugh Dickins
2022-12-01 15:52 ` Johannes Weiner
2022-12-01 19:28 ` Hugh Dickins
2022-11-30 12:50 ` Michal Hocko [this message]
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=Y4dRnxrVkdqLRi1v@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sfr@canb.auug.org.au \
--cc=shakeelb@google.com \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).