On Tue, Feb 19, 2019 at 12:41 PM Jason Gunthorpe [off-list ref] wrote:

On Tue, Feb 19, 2019 at 03:30:33PM -0500, Jerome Glisse wrote:

quoted

On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:

quoted

On Tue, Feb 19, 2019 at 12:04 PM [off-list ref] wrote:

quoted

From: Jérôme Glisse <redacted>

Since last version [4] i added the extra bits needed for the change_pte
optimization (which is a KSM thing). Here i am not posting users of
this, they will be posted to the appropriate sub-systems (KVM, GPU,
RDMA, ...) once this serie get upstream. If you want to look at users
of this see [5] [6]. If this gets in 5.1 then i will be submitting
those users for 5.2 (including KVM if KVM folks feel comfortable with
it).

The users look small and straightforward. Why not await acks and
reviewed-by's for the users like a typical upstream submission and
merge them together? Is all of the functionality of this
infrastructure consumed by the proposed users? Last time I checked it
was only a subset.

Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
vs UNMAP. Both of which i intend to use. The RDMA folks already ack
the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
were ok with it too. I do not want to merge things through Andrew
for all of this we discussed that in the past, merge mm bits through
Andrew in one release and bits that use things in the next release.

It is usually cleaner for everyone to split patches like this, for
instance I always prefer to merge RDMA patches via RDMA when
possible. Less conflicts.

The other somewhat reasonable option is to get acks and send your own
complete PR to Linus next week? That works OK for tree-wide changes.

Yes, I'm not proposing that they be merged together, instead I'm just
looking for the acked-by / reviewed-by tags even if those patches are
targeting the next merge window.