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.
next prev parent 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).