LKML Archive on
help / color / mirror / Atom feed
From: Jason Gunthorpe <>
To: Andrew Morton <>
Cc: Christoph Hellwig <>,
	Mark Rutland <>,
	Robin Murphy <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	Michal Hocko <>,
	Dan Williams <>
Subject: Re: [PATCH v3 0/4] Devmap cleanups + arm64 support
Date: Thu, 4 Jul 2019 19:59:38 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jul 04, 2019 at 11:53:24AM -0700, Andrew Morton wrote:
> On Wed, 26 Jun 2019 20:35:51 -0700 Andrew Morton <> wrote:
> > > Let me know and I can help orchestate this.
> > 
> > Well.  Whatever works.  In this situation I'd stage the patches after
> > linux-next and would merge them up after the prereq patches have been
> > merged into mainline.  Easy.
> All right, what the hell just happened? 

Christoph's patch series for the devmap & hmm rework finally made it
into linux-next, sorry, it took quite a few iterations on the list to
get all the reviews and tests, and figure out how to resolve some
other conflicting things. So it just made it this week.

Recall, this is the patch series I asked you about routing a few weeks
ago, as it really exceeded the small area that hmm.git was supposed to
cover. I think we are both caught off guard how big the conflict is!

> A bunch of new material has just been introduced into linux-next.
> I've partially unpicked the resulting mess, haven't dared trying to
> compile it yet.  To get this far I'll need to drop two patch series
> and one individual patch:
> mm-clean-up-is_device__page-definitions.patch
> mm-introduce-arch_has_pte_devmap.patch
> arm64-mm-implement-pte_devmap-support.patch
> arm64-mm-implement-pte_devmap-support-fix.patch

This one we discussed, and I thought we agreed would go to your 'stage
after linux-next' flow (see above). I think the conflict was minor

> mm-sparsemem-introduce-struct-mem_section_usage.patch
> mm-sparsemem-introduce-a-section_is_early-flag.patch
> mm-sparsemem-add-helpers-track-active-portions-of-a-section-at-boot.patch
> mm-hotplug-prepare-shrink_zone-pgdat_span-for-sub-section-removal.patch
> mm-sparsemem-convert-kmalloc_section_memmap-to-populate_section_memmap.patch
> mm-hotplug-kill-is_dev_zone-usage-in-__remove_pages.patch
> mm-kill-is_dev_zone-helper.patch
> mm-sparsemem-prepare-for-sub-section-ranges.patch
> mm-sparsemem-support-sub-section-hotplug.patch
> mm-document-zone_device-memory-model-implications.patch
> mm-document-zone_device-memory-model-implications-fix.patch
> mm-devm_memremap_pages-enable-sub-section-remap.patch
> libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch
> libnvdimm-pfn-stop-padding-pmem-namespaces-to-section-alignment.patch

Dan pointed to this while reviewing CH's series and said the conflicts
would be manageable, but they are certainly larger than I expected!

This series is the one that seems to be the really big trouble. I
already checked all the other stuff that Stephen resolved, and it
looks OK and managable. Just this one conflict with kernel/memremap.c
is beyond me. 

What approach do you want to take to go forward? Here are some thoughts:

CH has said he is away for the long weekend, so the path that involves
the fewest people is if Dan respins the above on linux-next and it
goes later with the arm patches above, assuming defering it for now
has no other adverse effects on -mm.

Pushing CH's series to -mm would need a respin on top of Dan's series
above and would need to carry along the whole hmm.git (about 44
patches). Signs are that this could be managed with the code currently
in the GPU trees.

If we give up on CH's series the hmm.git will not have conflicts,
however we just kick the can to the next merge window where we will be
back to having to co-ordinate amd/nouveau/rdma git trees and -mm's
patch workflow - and I think we will be worse off as we will have
totally given up on a git based work flow for this. :(

> mm-sparsemem-cleanup-section-number-data-types.patch
> mm-sparsemem-cleanup-section-number-data-types-fix.patch

Stephen used a minor conflict resolution for this one, I checked it
carefully and it looked OK.

> I thought you were just going to move material out of -mm and into
> hmm.git.  

Dan brought up a patch from Ira conflicting with CH's work and we did
handle that by moving a single patch, as well I moved several hmm
specific patches early in the cycle.

> Didn't begin to suspect that new and quite disruptive material would
> be introduced late in -rc7!!

Unfortunately a non-rebasing tree like hmm.git should only get patches
into linux-next once they are fully reviewed and done on the list. I
did not attempt to run separately patches 'under review' into
linux-next as you do. 

Actually I didn't even know this would benefit your workflow, rebasing
patches on top of linux-next is not part of the git based workflow I'm
using :(

AFAIK Dan and CH were both tracking conflicts with linux-next, so I'd
like to hear from Dan what he thinks about his series, maybe the
rebase is simple & safe for him? Dan and CH were working pretty
closely on CH's series.


  reply	other threads:[~2019-07-04 19:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 15:03 Robin Murphy
2019-05-23 15:03 ` [PATCH v3 1/4] mm/memremap: Rename and consolidate SECTION_SIZE Robin Murphy
2019-05-23 15:03 ` [PATCH v3 2/4] mm: clean up is_device_*_page() definitions Robin Murphy
2019-05-23 15:03 ` [PATCH v3 3/4] mm: introduce ARCH_HAS_PTE_DEVMAP Robin Murphy
2019-05-23 15:03 ` [PATCH v3 4/4] arm64: mm: Implement pte_devmap support Robin Murphy
2019-05-24 18:08   ` Will Deacon
2019-05-24 18:38     ` Robin Murphy
2019-05-27  6:23     ` Anshuman Khandual
2019-05-28 13:46   ` [PATCH v3.1 " Robin Murphy
2019-05-29 10:03     ` Will Deacon
2019-06-26  7:35 ` [PATCH v3 0/4] Devmap cleanups + arm64 support Christoph Hellwig
2019-06-26 12:31   ` Mark Rutland
2019-06-26 15:38     ` Christoph Hellwig
2019-06-26 15:45       ` Jason Gunthorpe
2019-06-27  3:35         ` Andrew Morton
2019-07-04 18:53           ` Andrew Morton
2019-07-04 19:59             ` Jason Gunthorpe [this message]
2019-07-04 20:53               ` Andrew Morton
2019-07-04 21:28                 ` Jason Gunthorpe
2019-07-05 15:47                   ` Jason Gunthorpe
2019-07-04 20:54               ` Robin Murphy
2019-07-04 21:13                 ` Andrew Morton
2019-07-05 11:16                   ` Robin Murphy
2019-07-04 23:37               ` Dan Williams
2019-07-05 12:32                 ` Jason Gunthorpe

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v3 0/4] Devmap cleanups + arm64 support' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).