From: Minchan Kim <minchan@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, John Dias <joaodias@google.com>,
Tim Murray <timmurray@google.com>
Subject: Re: [PATCH] mm: don't be stuck to rmap lock on reclaim path
Date: Wed, 4 May 2022 08:52:13 -0700 [thread overview]
Message-ID: <YnKhLX+jzJc+2KwB@google.com> (raw)
In-Reply-To: <YnIYofrw/GGEvc0U@casper.infradead.org>
On Wed, May 04, 2022 at 07:09:37AM +0100, Matthew Wilcox wrote:
> On Tue, May 03, 2022 at 09:30:38PM -0700, Minchan Kim wrote:
> > On Wed, May 04, 2022 at 04:32:13AM +0100, Matthew Wilcox wrote:
> > > On Tue, May 03, 2022 at 10:03:41AM -0700, Minchan Kim wrote:
> > > > -void rmap_walk(struct folio *folio, const struct rmap_walk_control *rwc);
> > > > -void rmap_walk_locked(struct folio *folio, const struct rmap_walk_control *rwc);
> > > > +void rmap_walk(struct folio *folio, struct rmap_walk_control *rwc);
> > > > +void rmap_walk_locked(struct folio *folio, struct rmap_walk_control *rwc);
> > >
> > > I see the build bot already beat me to pointing out why this is wrong,
> > > but do you not look at git log to figure out why code was changed to be
> > > the way it is now, before you change it back?
> >
> > This patch added a new field as out param like compact_control so
> > the rmap_walk_control is not immutable.
>
> ... but we have a user which treats it as if it is.
True. I don't think it will show sizable benefit on runtime overhead
since rmap_walk is already one of the most expensive operation in MM.
I could reintroduce the typecast for page_idle_clear_pte_refs to remove
the const as we had several years.
If your concern was to make rmap_walk_control mutable back, I could
change rmap_walk function having return value or adding a addtional
new out param. However, I thought rmap_walk_control is more readable/
easier than them.
next prev parent reply other threads:[~2022-05-04 15:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 17:03 [PATCH] mm: don't be stuck to rmap lock on reclaim path Minchan Kim
2022-05-04 2:13 ` kernel test robot
2022-05-04 3:24 ` kernel test robot
2022-05-04 3:32 ` Matthew Wilcox
2022-05-04 4:30 ` Minchan Kim
2022-05-04 6:09 ` Matthew Wilcox
2022-05-04 15:52 ` Minchan Kim [this message]
2022-05-04 16:55 ` Matthew Wilcox
2022-05-04 23:47 ` Minchan Kim
2022-05-05 0:42 ` Matthew Wilcox
2022-05-05 6:11 ` Minchan Kim
2022-05-17 23:58 ` Andrew Morton
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=YnKhLX+jzJc+2KwB@google.com \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=joaodias@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=surenb@google.com \
--cc=timmurray@google.com \
--cc=willy@infradead.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 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.