All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kuehling, Felix" <Felix.Kuehling@amd.com>
To: Jason Gunthorpe <jgg@ziepe.ca>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"airlied@gmail.com" <airlied@gmail.com>
Cc: "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 19:16:48 +0000	[thread overview]
Message-ID: <c42a620d-ce5f-def3-32e3-1e5482a2540e@amd.com> (raw)
In-Reply-To: <20190606151149.GA5506@ziepe.ca>

[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

WARNING: multiple messages have this Message-ID (diff)
From: "Kuehling, Felix" <Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>
To: Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org>,
	"Deucher,
	Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
	"airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"
	<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	"jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
	<jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 0/2] Two bug-fixes for HMM
Date: Thu, 6 Jun 2019 19:16:48 +0000	[thread overview]
Message-ID: <c42a620d-ce5f-def3-32e3-1e5482a2540e@amd.com> (raw)
In-Reply-To: <20190606151149.GA5506-uk2M96/98Pc@public.gmane.org>

[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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2019-06-06 19:16 UTC|newest]

Thread overview: 36+ 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 ` Kuehling, Felix
2019-05-10 19:53 ` [PATCH 1/2] mm/hmm: support automatic NUMA balancing Kuehling, Felix
2019-05-10 19:53   ` Kuehling, Felix
2019-05-10 20:13   ` Jerome Glisse
2019-05-10 20:13     ` Jerome Glisse
2019-05-13 21:27   ` Andrew Morton
2019-05-13 21:27     ` Andrew Morton
2019-05-13 22:37     ` Jerome Glisse
2019-05-13 22:37       ` Jerome Glisse
2019-05-14 21:14     ` Kuehling, Felix
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 19:53   ` Kuehling, Felix
2019-05-10 20:14   ` Jerome Glisse
2019-05-10 20:14     ` Jerome Glisse
2019-05-13 19:36     ` Kuehling, Felix
2019-05-13 19:36       ` Kuehling, Felix
2019-05-13 19:49       ` Jerome Glisse
2019-05-13 19:49         ` Jerome Glisse
2019-05-13 20:31         ` Kuehling, Felix
2019-05-13 20:31           ` Kuehling, Felix
2019-05-13 20:21       ` Deucher, Alexander
2019-05-13 20:21         ` Deucher, Alexander
2019-05-14 21:12         ` Kuehling, Felix
2019-05-14 21:12           ` Kuehling, Felix
2019-05-14 21:58           ` Alex Deucher
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 15:11   ` Jason Gunthorpe
2019-06-06 19:04   ` Kuehling, Felix
2019-06-06 19:04     ` Kuehling, Felix
2019-06-06 19:20     ` Jason Gunthorpe
2019-06-06 19:20       ` Jason Gunthorpe
2019-06-06 19:16   ` Kuehling, Felix [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=c42a620d-ce5f-def3-32e3-1e5482a2540e@amd.com \
    --to=felix.kuehling@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@ziepe.ca \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.