[PATCH 0/2] Two bug-fixes for HMM

[Jason Gunthorpe]

On Thu, Jun 06, 2019 at 07:04:46PM +0000, Kuehling, Felix wrote:
> On 2019-06-06 11:11 a.m., Jason Gunthorpe wrote:
> > On Fri, May 10, 2019 at 07:53:21PM +0000, Kuehling, Felix wrote:
> >> These problems were found in AMD-internal testing as we're working on
> >> adopting HMM. They are rebased against glisse/hmm-5.2-v3. We'd like to get
> >> them applied to a mainline Linux kernel as well as drm-next and
> >> amd-staging-drm-next sooner rather than later.
> >>
> >> Currently the HMM in amd-staging-drm-next is quite far behind hmm-5.2-v3,
> >> but the driver changes for HMM are expected to land in 5.2 and will need to
> >> be rebased on those HMM changes.
> >>
> >> I'd like to work out a flow between Jerome, Dave, Alex and myself that
> >> allows us to test the latest version of HMM on amd-staging-drm-next so
> >> that ideally everything comes together in master without much need for
> >> rebasing and retesting.
> > I think we have that now, I'm running a hmm.git that is clean and can
> > be used for merging into DRM related trees (and RDMA). I've commited
> > to send this tree to Linus at the start of the merge window.
> >
> > See here:
> >
> >   https://lore.kernel.org/lkml/20190524124455.GB16845@ziepe.ca/
> >
> > The tree is here:
> >
> >   https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=hmm
> >
> > However please consult with me before making a merge commit to be
> > co-ordinated. Thanks
> >
> > I see in this thread that AMDGPU missed 5.2 beacause of the
> > co-ordination problems this tree is intended to solve, so I'm very
> > hopeful this will help your work move into 5.3!
> 
> Thanks Jason. Our two patches below were already included in the MM tree 
> (https://ozlabs.org/~akpm/mmots/broken-out/). With your new hmm.git, 
> does that mean HMM fixes and changes will no longer go through Andrew 
> Morton but directly through your tree to Linus?

I belive so, that is what we agreed to in the RFC. At least for this
cycle.

I already noticed the duplication and sent Andrew a separate note..

It will be best if most of the things touching mm/hmm.c go to hmm.git
to avoid conflicts for Linus.

> We have also applied the two patches to our internal tree which is 
> currently based on 5.2-rc1 so we can make progress.

Makes sense, this is is also why this shared tree should be very
helpful..

I intend to run it as a clean and stable non-rebasing tree, ah
probably starting tomorrow since I see there is still another
fixup. :)

> Alex, I think merging hmm would be an extra step every time you rebase
> amd-staging-drm-next. We could probably also merge hmm at other times as
> needed. Do you think this would cause trouble or confusion for 
> upstreaming through drm-next?

I'm not sure what the workflow the amd tree uses, but..

Broadly: If the AMD tree is rebasing then likely you can simply rebase
your AMD tree on top of hmm.git (or maybe hmm.git merge'd into
DRM).

Most likely we will want to send a PR for hmm.git to main DRM tree
prior to merging AMD's tree, but I'm also rather relying on DRM folks
to help build the workflow they want in their world..

There are quite a few options depending on people's preferences and
workflow.

Thanks,
Jason