On Tue, Feb 19, 2019 at 03:30:33PM -0500, Jerome Glisse wrote: > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote: > > On Tue, Feb 19, 2019 at 12:04 PM <jglisse@xxxxxxxxxx> wrote: > > > > > > From: Jérôme Glisse <jglisse@xxxxxxxxxx> > > > > > > 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. Jason
