From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Kuehling, Felix" <Felix.Kuehling@amd.com>
Cc: "alex.deucher@amd.com" <alex.deucher@amd.com>,
"airlied@gmail.com" <airlied@gmail.com>,
"jglisse@redhat.com" <jglisse@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 0/2] Two bug-fixes for HMM
Date: Thu, 6 Jun 2019 16:20:01 -0300 [thread overview]
Message-ID: <20190606192001.GE17373@ziepe.ca> (raw)
In-Reply-To: <1d309300-41d8-eb31-38c2-c6c9dd5c0ba8@amd.com>
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
next prev parent reply other threads:[~2019-06-06 19:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 19:53 [PATCH 0/2] Two bug-fixes for HMM Kuehling, Felix
2019-05-10 19:53 ` [PATCH 1/2] mm/hmm: support automatic NUMA balancing Kuehling, Felix
2019-05-10 20:13 ` Jerome Glisse
2019-05-13 21:27 ` Andrew Morton
2019-05-13 22:37 ` Jerome Glisse
2019-05-14 21:14 ` Kuehling, Felix
2019-05-10 19:53 ` [PATCH 2/2] mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking Kuehling, Felix
2019-05-10 20:14 ` Jerome Glisse
2019-05-13 19:36 ` Kuehling, Felix
2019-05-13 19:49 ` Jerome Glisse
2019-05-13 20:31 ` Kuehling, Felix
2019-05-13 20:21 ` Deucher, Alexander
2019-05-14 21:12 ` Kuehling, Felix
2019-05-14 21:58 ` Alex Deucher
2019-06-06 15:11 ` [PATCH 0/2] Two bug-fixes for HMM Jason Gunthorpe
2019-06-06 19:04 ` Kuehling, Felix
2019-06-06 19:20 ` Jason Gunthorpe [this message]
2019-06-06 19:16 ` Kuehling, Felix
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=20190606192001.GE17373@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=Felix.Kuehling@amd.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alex.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jglisse@redhat.com \
--cc=linux-mm@kvack.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).