linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	linux-mm@kvack.org,
	William Kucharski <william.kucharski@oracle.com>,
	Mike Rapoport <rppt@kernel.org>,
	Alistair Popple <apopple@nvidia.com>,
	Alex Sierra <alex.sierra@amd.com>, Christoph Hellwig <hch@lst.de>,
	Hugh Dickins <hughd@google.com>
Subject: Re: linux-next: manual merge of the akpm-current tree with the folio tree
Date: Thu, 17 Feb 2022 21:19:43 +0000	[thread overview]
Message-ID: <Yg6778VW5JX512GL@casper.infradead.org> (raw)
In-Reply-To: <20220217173810.0addd3ed@canb.auug.org.au>

On Thu, Feb 17, 2022 at 05:38:10PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 16 Feb 2022 21:51:24 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 17 Feb 2022 16:30:26 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > On Wed, 16 Feb 2022 20:41:35 +0000 Matthew Wilcox <willy@infradead.org> wrote:  
> > > >
> > > > So where do we go from here?  I can see ways of resolving this if
> > > > Andrew switches to git, but he won't, so that's out.  Perhaps I can
> > > > publish a git tree of Hugh's mlock patches and Christoph's series,
> > > > and you can pull that before Andrew's tree so git resolves the conflicts
> > > > early before trying to resolve conflicts against my tree?  
> > > 
> > > My response for any other subsystem would be that you need to go
> > > through the maintainer's tree.  In this case that means feeding a patch
> > > series to Andrew and updating that patch series.
> > > 
> > > Alternatively, you need to find someone (with Andrew's agreement) who
> > > can maintain a git tree that includes all Andrew's MM patches and any
> > > other topic branches and deals with all the conflicts and can feed it
> > > all to Linus.  Linux-next would also include that tree/branch.
> > > 
> > > Andrew, do you have any comments?  
> > 
> > Let's try Matthew's idea - I'll get Hugh's and Christoph's series via
> > linux-next and shall figure out the rest.
> 
> OK, but I am on vacation from tomorrow until Feb 28th, so I will assume
> you will have it all ready for me by then.

I assume you mean that you'll do one last pull and release a
next-20220218, rather than saying that the next release will be
next-20220229?

I have pushed out f82e2137bc1e to infradead/for-next.  xfstests currently
running.  It includes:

Alex Sierra (10):
      mm: add zone device coherent type memory support
      mm: add device coherent vma selection for memory migration
      mm/gup: fail get_user_pages for LONGTERM dev coherent type
      drm/amdkfd: add SPM support for SVM
      drm/amdkfd: coherent type as sys mem on migration to ram
      lib: test_hmm add ioctl to get zone device type
      lib: test_hmm add module param for zone device type
      lib: add support for device coherent type in test_hmm
      tools: update hmm-test to support device coherent type
      tools: update test_hmm script to support SP config

Alistair Popple (2):
      mm: remove the vma check in migrate_vma_setup()
      mm/gup: migrate device coherent pages when pinning instead of failing

Christoph Hellwig (14):
      mm: remove a pointless CONFIG_ZONE_DEVICE check in memremap_pages
      mm: remove the __KERNEL__ guard from <linux/mm.h>
      mm: remove pointless includes from <linux/hmm.h>
      mm: move free_devmap_managed_page to memremap.c
      mm: simplify freeing of devmap managed pages
      mm: don't include <linux/memremap.h> in <linux/mm.h>
      mm: remove the extra ZONE_DEVICE struct page refcount
      fsdax: depend on ZONE_DEVICE || FS_DAX_LIMITED
      mm: generalize the pgmap based page_free infrastructure
      mm: refactor check_and_migrate_movable_pages
      mm: refactor the ZONE_DEVICE handling in migrate_vma_insert_page
      mm: refactor the ZONE_DEVICE handling in migrate_vma_pages
      mm: move the migrate_vma_* device migration code into its own file
      mm: build migrate_vma_* for all configs with ZONE_DEVICE support

Hugh Dickins (13):
      mm/munlock: delete page_mlock() and all its works
      mm/munlock: delete FOLL_MLOCK and FOLL_POPULATE
      mm/munlock: delete munlock_vma_pages_all(), allow oomreap
      mm/munlock: rmap call mlock_vma_page() munlock_vma_page()
      mm/munlock: replace clear_page_mlock() by final clearance
      mm/munlock: maintain page->mlock_count while unevictable
      mm/munlock: mlock_pte_range() when mlocking or munlocking
      mm/migrate: __unmap_and_move() push good newpage to LRU
      mm/munlock: delete smp_mb() from __pagevec_lru_add_fn()
      mm/munlock: mlock_page() munlock_page() batch by pagevec
      mm/munlock: page migration needs mlock pagevec drained
      mm/thp: collapse_file() do try_to_unmap(TTU_BATCH_FLUSH)
      mm/thp: shrink_page_list() avoid splitting VM_LOCKED THP

Matthew Wilcox (Oracle) (83):
[skipped]

Mike Rapoport (1):
      arch: Add pmd_pfn() where it is missing

William Kucharski (1):
      mm/readahead: Align file mappings for non-DAX


I squashed in the various -fix patches that were in the akpm or next
trees.  I hope I didn't miss anything important.

https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/for-next
if anyone wants to browse and tell me if I messed something up.

  reply	other threads:[~2022-02-17 21:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15  7:00 linux-next: manual merge of the akpm-current tree with the folio tree Stephen Rothwell
2022-02-15 13:12 ` Matthew Wilcox
2022-02-16  6:21   ` Stephen Rothwell
2022-02-16  9:49     ` Stephen Rothwell
2022-02-16 20:41     ` Matthew Wilcox
2022-02-17  5:30       ` Stephen Rothwell
2022-02-17  5:51         ` Andrew Morton
2022-02-17  6:38           ` Stephen Rothwell
2022-02-17 21:19             ` Matthew Wilcox [this message]
2022-02-19  7:27               ` Christoph Hellwig
2022-02-20  0:17               ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-04-08  5:18 Stephen Rothwell
2022-04-08  5:08 Stephen Rothwell
2022-03-22  8:35 Stephen Rothwell
2022-02-16  6:15 Stephen Rothwell
2021-12-10 21:17 broonie
2021-07-21  6:31 Stephen Rothwell
2021-09-06  4:48 ` Stephen Rothwell
2021-09-06 12:12   ` Matthew Wilcox
2021-09-06 16:56     ` Suren Baghdasaryan
2021-09-06 21:35       ` Stephen Rothwell
2021-09-07 13:49   ` Matthew Wilcox
2021-07-21  6:02 Stephen Rothwell
2021-09-06  4:49 ` Stephen Rothwell

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=Yg6778VW5JX512GL@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.sierra@amd.com \
    --cc=apopple@nvidia.com \
    --cc=hch@lst.de \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-next@vger.kernel.org \
    --cc=rppt@kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=william.kucharski@oracle.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 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).