| Message ID | 20190510195258.9930-1-Felix.Kuehling@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Two bug-fixes for HMM | expand |
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! > Maybe having Jerome's latest HMM changes in drm-next. However, that may > create dependencies where Jerome and Dave need to coordinate their pull- > requests for master. > > Felix Kuehling (1): > mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking > > Philip Yang (1): > mm/hmm: support automatic NUMA balancing I've applied both of these patches with Jerome's Reviewed-by to hmm.git and added the missed Signed-off-by If you test and confirm I think this branch would be ready for merging toward the AMD tree. Regards, Jason
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? We have also applied the two patches to our internal tree which is currently based on 5.2-rc1 so we can make progress. 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? Regards, Felix > >> Maybe having Jerome's latest HMM changes in drm-next. However, that may >> create dependencies where Jerome and Dave need to coordinate their pull- >> requests for master. >> >> Felix Kuehling (1): >> mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking >> >> Philip Yang (1): >> mm/hmm: support automatic NUMA balancing > I've applied both of these patches with Jerome's Reviewed-by to > hmm.git and added the missed Signed-off-by > > If you test and confirm I think this branch would be ready for merging > toward the AMD tree. > Regards, > Jason
[resent with correct address for Alex] 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? We have also applied the two patches to our internal tree which is currently based on 5.2-rc1 so we can make progress. 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? Regards, Felix > >> Maybe having Jerome's latest HMM changes in drm-next. However, that may >> create dependencies where Jerome and Dave need to coordinate their pull- >> requests for master. >> >> Felix Kuehling (1): >> mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking >> >> Philip Yang (1): >> mm/hmm: support automatic NUMA balancing > I've applied both of these patches with Jerome's Reviewed-by to > hmm.git and added the missed Signed-off-by > > If you test and confirm I think this branch would be ready for merging > toward the AMD tree. > Regards, > Jason
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