From: Jerome Glisse <jglisse@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Christian König" <christian.koenig@amd.com>,
"Jan Kara" <jack@suse.cz>,
"Felix Kuehling" <Felix.Kuehling@amd.com>,
"Jason Gunthorpe" <jgg@mellanox.com>,
"Matthew Wilcox" <mawilcox@microsoft.com>,
"Ross Zwisler" <zwisler@kernel.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"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@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-rdma@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCH v4 0/9] mmu notifier provide context informations
Date: Thu, 31 Jan 2019 15:33:59 -0500 [thread overview]
Message-ID: <20190131203359.GA22145@redhat.com> (raw)
In-Reply-To: <20190131115535.7eeecf501615f8bad2f139eb@linux-foundation.org>
On Thu, Jan 31, 2019 at 11:55:35AM -0800, Andrew Morton wrote:
> On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse <jglisse@redhat.com> wrote:
>
> > Andrew what is your plan for this ? I had a discussion with Peter Xu
> > and Andrea about change_pte() and kvm. Today the change_pte() kvm
> > optimization is effectively disabled because of invalidate_range
> > calls. With a minimal couple lines patch on top of this patchset
> > we can bring back the kvm change_pte optimization and we can also
> > optimize some other cases like for instance when write protecting
> > after fork (but i am not sure this is something qemu does often so
> > it might not help for real kvm workload).
> >
> > I will be posting a the extra patch as an RFC, but in the meantime
> > i wanted to know what was the status for this.
>
> The various drm patches appear to be headed for collisions with drm
> tree development so we'll need to figure out how to handle that and in
> what order things happen.
>
> It's quite unclear from the v4 patchset's changelogs that this has
> anything to do with KVM and "the change_pte() kvm optimization" hasn't
> been described anywhere(?).
>
> So.. I expect the thing to do here is to get everything finished, get
> the changelogs completed with this new information and do a resend.
>
> Can we omit the drm and rdma patches for now? Feed them in via the
> subsystem maintainers when the dust has settled?
Yes, i should have pointed out that you can ignore the driver patches
i will resumit them through the appropriate tree once the mm bits are
in. I just wanted to show case how i intended to use this. I will try
not to forget next time to clearly tag things that are just there to
show case and that will be merge latter through different tree.
I will do a v5 with kvm bits once we have enough testing and confidence.
So i guess this all will be delayed to 5.2 and 5.3 for driver bits.
The kvm bits are outcomes of private emails and previous face to face
discussion around mmu notifier and kvm. I believe the context information
will turn to be useful to more users than the ones i am doing it for.
Cheers,
Jérôme
next prev parent reply other threads:[~2019-01-31 20:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 22:23 [PATCH v4 0/9] mmu notifier provide context informations jglisse
2019-01-23 22:23 ` [PATCH v4 1/9] mm/mmu_notifier: contextual information for event enums jglisse
2019-01-23 22:23 ` [PATCH v4 2/9] mm/mmu_notifier: contextual information for event triggering invalidation jglisse
2019-01-23 22:23 ` [PATCH v4 3/9] mm/mmu_notifier: use correct mmu_notifier events for each invalidation jglisse
2019-01-23 22:23 ` [PATCH v4 4/9] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening jglisse
2019-01-23 22:23 ` [PATCH v4 5/9] mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper jglisse
2019-01-23 22:23 ` [PATCH v4 6/9] gpu/drm/radeon: optimize out the case when a range is updated to read only jglisse
2019-01-23 22:23 ` [PATCH v4 7/9] gpu/drm/amdgpu: " jglisse
2019-01-23 22:23 ` [PATCH v4 8/9] gpu/drm/i915: " jglisse
2019-01-24 12:09 ` Joonas Lahtinen
2019-01-24 15:30 ` Jerome Glisse
[not found] ` <154877159986.4387.16328989441685542244@jlahtine-desk.ger.corp.intel.com>
2019-01-29 16:21 ` Jerome Glisse
2019-01-23 22:23 ` [PATCH v4 9/9] RDMA/umem_odp: " jglisse
2019-01-23 22:32 ` Jason Gunthorpe
2019-01-23 22:46 ` Jerome Glisse
2019-01-23 22:54 ` [PATCH v4 0/9] mmu notifier provide context informations Dan Williams
2019-01-23 23:04 ` Jerome Glisse
2019-01-24 0:00 ` Dan Williams
2019-01-31 16:10 ` Jerome Glisse
2019-01-31 19:55 ` Andrew Morton
2019-01-31 20:33 ` Jerome Glisse [this message]
2019-02-01 12:24 ` Christian König
2019-02-01 21:02 ` Jan Kara
2019-02-11 18:54 ` 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=20190131203359.GA22145@redhat.com \
--to=jglisse@redhat.com \
--cc=Felix.Kuehling@amd.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=christian.koenig@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jack@suse.cz \
--cc=jgg@mellanox.com \
--cc=jhubbard@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mawilcox@microsoft.com \
--cc=mhocko@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rcampbell@nvidia.com \
--cc=rkrcmar@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).