All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Jerome Glisse <jglisse@redhat.com>
Cc: "Linux MM" <linux-mm@kvack.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Jan Kara" <jack@suse.cz>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	"Felix Kuehling" <Felix.Kuehling@amd.com>,
	"Jason Gunthorpe" <jgg@mellanox.com>,
	"Ross Zwisler" <zwisler@kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"KVM list" <kvm@vger.kernel.>
Subject: Re: [PATCH v5 0/9] mmu notifier provide context informations
Date: Tue, 19 Feb 2019 12:40:37 -0800	[thread overview]
Message-ID: <CAPcyv4gUFSA6u77dGA6XxO41217zQ27DNteiHRG515Gtm_uGgg@mail.gmail.com> (raw)
In-Reply-To: <20190219203032.GC3959@redhat.com>

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

Ok, I was trying to find the links to the acks on the mailing list,
those references would address my concerns. I see no reason to rush
SOFT_DIRTY and CLEAR ahead of the upstream user.

WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Jerome Glisse <jglisse@redhat.com>
Cc: "Linux MM" <linux-mm@kvack.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Jan Kara" <jack@suse.cz>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	"Felix Kuehling" <Felix.Kuehling@amd.com>,
	"Jason Gunthorpe" <jgg@mellanox.com>,
	"Ross Zwisler" <zwisler@kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"KVM list" <kvm@vger.kernel.org>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	linux-rdma <linux-rdma@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCH v5 0/9] mmu notifier provide context informations
Date: Tue, 19 Feb 2019 12:40:37 -0800	[thread overview]
Message-ID: <CAPcyv4gUFSA6u77dGA6XxO41217zQ27DNteiHRG515Gtm_uGgg@mail.gmail.com> (raw)
In-Reply-To: <20190219203032.GC3959@redhat.com>

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

Ok, I was trying to find the links to the acks on the mailing list,
those references would address my concerns. I see no reason to rush
SOFT_DIRTY and CLEAR ahead of the upstream user.

  parent reply	other threads:[~2019-02-19 20:40 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-19 20:04 [PATCH v5 0/9] mmu notifier provide context informations jglisse
2019-02-19 20:04 ` jglisse
2019-02-19 20:04 ` [PATCH v5 1/9] mm/mmu_notifier: helper to test if a range invalidation is blockable jglisse
2019-02-19 20:04   ` jglisse
2019-02-22 19:01   ` Ralph Campbell
2019-02-22 19:01     ` Ralph Campbell
2019-02-22 19:01     ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 2/9] mm/mmu_notifier: convert user range->blockable to helper function jglisse
2019-02-19 20:04   ` jglisse
2019-02-22 19:02   ` Ralph Campbell
2019-02-22 19:02     ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 3/9] mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags jglisse
2019-02-19 20:04   ` jglisse
2019-02-22 19:04   ` Ralph Campbell
2019-02-22 19:04     ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 4/9] mm/mmu_notifier: contextual information for event enums jglisse
2019-02-19 20:04   ` jglisse
2019-02-22 19:26   ` Ralph Campbell
2019-02-22 19:26     ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 5/9] mm/mmu_notifier: contextual information for event triggering invalidation v2 jglisse
2019-02-19 20:04   ` jglisse
2019-02-22 21:25   ` Ralph Campbell
2019-02-22 21:25     ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 6/9] mm/mmu_notifier: use correct mmu_notifier events for each invalidation jglisse
2019-02-19 20:04   ` jglisse
2019-02-22 22:07   ` Ralph Campbell
2019-02-22 22:07     ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 7/9] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2 jglisse
2019-02-19 20:04   ` jglisse
2019-02-22 22:08   ` Ralph Campbell
2019-02-22 22:08     ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 8/9] mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper jglisse
2019-02-19 20:04   ` jglisse
2019-02-22 22:42   ` Ralph Campbell
2019-02-22 22:42     ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 9/9] mm/mmu_notifier: set MMU_NOTIFIER_USE_CHANGE_PTE flag where appropriate v2 jglisse
2019-02-19 20:04   ` jglisse
2019-02-22 23:01   ` Ralph Campbell
2019-02-22 23:01     ` Ralph Campbell
2019-02-19 20:15 ` [PATCH v5 0/9] mmu notifier provide context informations Dan Williams
2019-02-19 20:15   ` Dan Williams
2019-02-19 20:30   ` Jerome Glisse
2019-02-19 20:30     ` Jerome Glisse
2019-02-19 20:40     ` Jason Gunthorpe
2019-02-19 20:40       ` Jason Gunthorpe
2019-02-19 20:49       ` Dan Williams
2019-02-19 20:49         ` Dan Williams
2019-02-19 20:40     ` Dan Williams [this message]
2019-02-19 20:40       ` Dan Williams
2019-02-19 20:57       ` Jerome Glisse
2019-02-19 20:57         ` Jerome Glisse
2019-02-19 21:19         ` Dan Williams
2019-02-19 21:19           ` Dan Williams
2019-02-19 21:30           ` Jerome Glisse
2019-02-19 21:30             ` Jerome Glisse

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=CAPcyv4gUFSA6u77dGA6XxO41217zQ27DNteiHRG515Gtm_uGgg@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=christian.koenig@amd.com \
    --cc=jack@suse.cz \
    --cc=jani.nikula@linux.intel.com \
    --cc=jgg@mellanox.com \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kvm@vger.kernel. \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=rcampbell@nvidia.com \
    --cc=rkrcmar@redhat.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=zwisler@kernel.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.