linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christoph Hellwig <hch@lst.de>
Cc: "Jason Gunthorpe" <jgg@mellanox.com>,
	"Christoph Hellwig" <hch@infradead.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Thomas Hellström" <thomas@shipmail.org>,
	"Jerome Glisse" <jglisse@redhat.com>,
	"Steven Price" <steven.price@arm.com>,
	Linux-MM <linux-mm@kvack.org>,
	"Linux List Kernel Mailing" <linux-kernel@vger.kernel.org>,
	"Minchan Kim" <minchan@kernel.org>
Subject: Re: cleanup the walk_page_range interface
Date: Fri, 16 Aug 2019 09:20:52 -0700	[thread overview]
Message-ID: <CAHk-=wiOB5wLWxHe8UDHnBB1DWrZaZ62ZPXnD0KiE8hYoWokNA@mail.gmail.com> (raw)
In-Reply-To: <20190816123258.GA22140@lst.de>

On Fri, Aug 16, 2019 at 5:33 AM Christoph Hellwig <hch@lst.de> wrote:
>
> I see two new walk_page_range user in linux-next related to MADV_COLD
> support (which probably really should use walk_range_vma), and then
> there is the series from Steven, which hasn't been merged yet.

It does sound like this might as well just be handled in linux-next,
and there's no big advantage in me pulling the walker cleanups early.

Honestly, even if it ends up being handled as a conflict resolution
issue (rather than some shared branch), it probably simply isn't all
that painful. We have those kinds of semantic conflicts all the time,
it doesn't worry me too much.

So I'm not worried about new _users_ of the page walker concurrently
with the page walker interface itself being cleaned up. Those kinds of
conflicts end up being "just make sure to update the new users to the
new interface when they get pulled". Happens all the time.

I'd be more worried about two different branches wanting to change the
internal implementation of the page walker itself, and the actual
*code* itself getting conflicts (as opposed to the interface vs users
kind of conflicts). Those kinds of conflicts can be messy. But it
sounds like Thomas Hellström's changes aren't that kind of thing.

I'm still willing to do the early merge if it turns out to be hugely
helpful, but from the discussion so far it does sound like "just merge
during 5.4 merge window" is perfectly fine.

               Linus


  reply	other threads:[~2019-08-16 16:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-08 15:42 cleanup the walk_page_range interface Christoph Hellwig
2019-08-08 15:42 ` [PATCH 1/3] mm: split out a new pagewalk.h header from mm.h Christoph Hellwig
2019-08-08 15:42 ` [PATCH 2/3] pagewalk: seperate function pointers from iterator data Christoph Hellwig
2019-08-08 20:34   ` Thomas Hellstrom
2019-08-09  8:57   ` Steven Price
2019-08-08 15:42 ` [PATCH 3/3] pagewalk: use lockdep_assert_held for locking validation Christoph Hellwig
2019-08-08 18:18   ` Matthew Wilcox
2019-08-08 17:50 ` cleanup the walk_page_range interface Linus Torvalds
2019-08-08 21:56   ` Christoph Hellwig
2019-08-08 22:21     ` Thomas Hellstrom
2019-08-09 14:36       ` Christoph Hellwig
2019-08-12  6:17     ` Mike Rapoport
2019-08-16  6:27   ` Christoph Hellwig
2019-08-16 11:57     ` Jason Gunthorpe
2019-08-16 12:32       ` Christoph Hellwig
2019-08-16 16:20         ` Linus Torvalds [this message]
2019-08-16 21:06         ` Andrew Morton
2019-08-17  6:41           ` Stephen Rothwell
2019-08-17  6:43             ` Christoph Hellwig
2019-08-17  6:58               ` Stephen Rothwell
2019-08-17  7:37             ` Linus Torvalds
2019-08-23 13:43     ` Jason Gunthorpe
2019-08-23 15:36       ` Steven Price
2019-08-24 22:26       ` Christoph Hellwig
2019-08-27  1:34         ` Jason Gunthorpe
2019-08-27 23:34           ` Andrew Morton
2019-08-27 23:36             ` Jason Gunthorpe
2019-08-28  6:20               ` Christoph Hellwig
2019-08-28 13:23               ` Steven Price

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='CAHk-=wiOB5wLWxHe8UDHnBB1DWrZaZ62ZPXnD0KiE8hYoWokNA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=jgg@mellanox.com \
    --cc=jglisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=steven.price@arm.com \
    --cc=thomas@shipmail.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).