From: Ralph Campbell <rcampbell@nvidia.com>
To: Jason Gunthorpe <jgg@mellanox.com>
Cc: <linux-rdma@vger.kernel.org>, <linux-mm@kvack.org>,
<nouveau@lists.freedesktop.org>, <kvm-ppc@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
"Jerome Glisse" <jglisse@redhat.com>,
John Hubbard <jhubbard@nvidia.com>,
"Christoph Hellwig" <hch@lst.de>,
Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <shuah@kernel.org>, Ben Skeggs <bskeggs@redhat.com>,
Bharata B Rao <bharata@linux.ibm.com>
Subject: Re: [PATCH v2 0/5] mm/migrate: avoid device private invalidations
Date: Mon, 20 Jul 2020 12:58:20 -0700 [thread overview]
Message-ID: <dd6ffaeb-df26-99e1-f6c5-bbe3e4153f04@nvidia.com> (raw)
In-Reply-To: <20200720184119.GT2021248@mellanox.com>
On 7/20/20 11:41 AM, Jason Gunthorpe wrote:
> On Mon, Jul 13, 2020 at 10:21:44AM -0700, Ralph Campbell wrote:
>> The goal for this series is to avoid device private memory TLB
>> invalidations when migrating a range of addresses from system
>> memory to device private memory and some of those pages have already
>> been migrated. The approach taken is to introduce a new mmu notifier
>> invalidation event type and use that in the device driver to skip
>> invalidation callbacks from migrate_vma_setup(). The device driver is
>> also then expected to handle device MMU invalidations as part of the
>> migrate_vma_setup(), migrate_vma_pages(), migrate_vma_finalize() process.
>> Note that this is opt-in. A device driver can simply invalidate its MMU
>> in the mmu notifier callback and not handle MMU invalidations in the
>> migration sequence.
>>
>> This series is based on Jason Gunthorpe's HMM tree (linux-5.8.0-rc4).
>>
>> Also, this replaces the need for the following two patches I sent:
>> ("mm: fix migrate_vma_setup() src_owner and normal pages")
>> https://lore.kernel.org/linux-mm/20200622222008.9971-1-rcampbell@nvidia.com
>> ("nouveau: fix mixed normal and device private page migration")
>> https://lore.kernel.org/lkml/20200622233854.10889-3-rcampbell@nvidia.com
>>
>> Changes in v2:
>> Rebase to Jason Gunthorpe's HMM tree.
>> Added reviewed-by from Bharata B Rao.
>> Rename the mmu_notifier_range::data field to migrate_pgmap_owner as
>> suggested by Jason Gunthorpe.
>
> I didn't see anything stand out in this at this point, did you intend
> this to go to the HMM tree?
>
> Thanks,
> Jason
Yes, please.
WARNING: multiple messages have this Message-ID (diff)
From: Ralph Campbell <rcampbell@nvidia.com>
To: Jason Gunthorpe <jgg@mellanox.com>
Cc: linux-rdma@vger.kernel.org, linux-mm@kvack.org,
nouveau@lists.freedesktop.org, kvm-ppc@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
Jerome Glisse <jglisse@redhat.com>,
John Hubbard <jhubbard@nvidia.com>,
Christoph Hellwig <hch@lst.de>,
Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <shuah@kernel.org>, Ben Skeggs <bskeggs@redhat.com>,
Bharata B Rao <bharata@linux.ibm.com>
Subject: Re: [PATCH v2 0/5] mm/migrate: avoid device private invalidations
Date: Mon, 20 Jul 2020 12:58:20 -0700 [thread overview]
Message-ID: <dd6ffaeb-df26-99e1-f6c5-bbe3e4153f04@nvidia.com> (raw)
In-Reply-To: <20200720184119.GT2021248@mellanox.com>
On 7/20/20 11:41 AM, Jason Gunthorpe wrote:
> On Mon, Jul 13, 2020 at 10:21:44AM -0700, Ralph Campbell wrote:
>> The goal for this series is to avoid device private memory TLB
>> invalidations when migrating a range of addresses from system
>> memory to device private memory and some of those pages have already
>> been migrated. The approach taken is to introduce a new mmu notifier
>> invalidation event type and use that in the device driver to skip
>> invalidation callbacks from migrate_vma_setup(). The device driver is
>> also then expected to handle device MMU invalidations as part of the
>> migrate_vma_setup(), migrate_vma_pages(), migrate_vma_finalize() process.
>> Note that this is opt-in. A device driver can simply invalidate its MMU
>> in the mmu notifier callback and not handle MMU invalidations in the
>> migration sequence.
>>
>> This series is based on Jason Gunthorpe's HMM tree (linux-5.8.0-rc4).
>>
>> Also, this replaces the need for the following two patches I sent:
>> ("mm: fix migrate_vma_setup() src_owner and normal pages")
>> https://lore.kernel.org/linux-mm/20200622222008.9971-1-rcampbell@nvidia.com
>> ("nouveau: fix mixed normal and device private page migration")
>> https://lore.kernel.org/lkml/20200622233854.10889-3-rcampbell@nvidia.com
>>
>> Changes in v2:
>> Rebase to Jason Gunthorpe's HMM tree.
>> Added reviewed-by from Bharata B Rao.
>> Rename the mmu_notifier_range::data field to migrate_pgmap_owner as
>> suggested by Jason Gunthorpe.
>
> I didn't see anything stand out in this at this point, did you intend
> this to go to the HMM tree?
>
> Thanks,
> Jason
Yes, please.
WARNING: multiple messages have this Message-ID (diff)
From: Ralph Campbell <rcampbell@nvidia.com>
To: Jason Gunthorpe <jgg@mellanox.com>
Cc: linux-rdma@vger.kernel.org, linux-mm@kvack.org,
nouveau@lists.freedesktop.org, kvm-ppc@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
Jerome Glisse <jglisse@redhat.com>,
John Hubbard <jhubbard@nvidia.com>,
Christoph Hellwig <hch@lst.de>,
Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <shuah@kernel.org>, Ben Skeggs <bskeggs@redhat.com>,
Bharata B Rao <bharata@linux.ibm.com>
Subject: Re: [PATCH v2 0/5] mm/migrate: avoid device private invalidations
Date: Mon, 20 Jul 2020 19:58:20 +0000 [thread overview]
Message-ID: <dd6ffaeb-df26-99e1-f6c5-bbe3e4153f04@nvidia.com> (raw)
In-Reply-To: <20200720184119.GT2021248@mellanox.com>
On 7/20/20 11:41 AM, Jason Gunthorpe wrote:
> On Mon, Jul 13, 2020 at 10:21:44AM -0700, Ralph Campbell wrote:
>> The goal for this series is to avoid device private memory TLB
>> invalidations when migrating a range of addresses from system
>> memory to device private memory and some of those pages have already
>> been migrated. The approach taken is to introduce a new mmu notifier
>> invalidation event type and use that in the device driver to skip
>> invalidation callbacks from migrate_vma_setup(). The device driver is
>> also then expected to handle device MMU invalidations as part of the
>> migrate_vma_setup(), migrate_vma_pages(), migrate_vma_finalize() process.
>> Note that this is opt-in. A device driver can simply invalidate its MMU
>> in the mmu notifier callback and not handle MMU invalidations in the
>> migration sequence.
>>
>> This series is based on Jason Gunthorpe's HMM tree (linux-5.8.0-rc4).
>>
>> Also, this replaces the need for the following two patches I sent:
>> ("mm: fix migrate_vma_setup() src_owner and normal pages")
>> https://lore.kernel.org/linux-mm/20200622222008.9971-1-rcampbell@nvidia.com
>> ("nouveau: fix mixed normal and device private page migration")
>> https://lore.kernel.org/lkml/20200622233854.10889-3-rcampbell@nvidia.com
>>
>> Changes in v2:
>> Rebase to Jason Gunthorpe's HMM tree.
>> Added reviewed-by from Bharata B Rao.
>> Rename the mmu_notifier_range::data field to migrate_pgmap_owner as
>> suggested by Jason Gunthorpe.
>
> I didn't see anything stand out in this at this point, did you intend
> this to go to the HMM tree?
>
> Thanks,
> Jason
Yes, please.
next prev parent reply other threads:[~2020-07-20 19:58 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 17:21 [PATCH v2 0/5] mm/migrate: avoid device private invalidations Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-13 17:21 ` [PATCH v2 1/5] nouveau: fix storing invalid ptes Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-13 17:21 ` [PATCH v2 2/5] mm/migrate: add a direction parameter to migrate_vma Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-20 18:36 ` Jason Gunthorpe
2020-07-20 18:36 ` Jason Gunthorpe
2020-07-20 18:36 ` Jason Gunthorpe
2020-07-20 19:54 ` Ralph Campbell
2020-07-20 19:54 ` Ralph Campbell
2020-07-20 19:54 ` Ralph Campbell
2020-07-20 19:59 ` Jason Gunthorpe
2020-07-20 19:59 ` Jason Gunthorpe
2020-07-20 19:59 ` Jason Gunthorpe
2020-07-20 20:49 ` Ralph Campbell
2020-07-20 20:49 ` Ralph Campbell
2020-07-20 20:49 ` Ralph Campbell
2020-07-20 23:16 ` Jason Gunthorpe
2020-07-20 23:16 ` Jason Gunthorpe
2020-07-20 23:16 ` Jason Gunthorpe
2020-07-20 23:53 ` Ralph Campbell
2020-07-20 23:53 ` Ralph Campbell
2020-07-20 23:53 ` Ralph Campbell
2020-07-13 17:21 ` [PATCH v2 3/5] mm/notifier: add migration invalidation type Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-20 18:40 ` Jason Gunthorpe
2020-07-20 18:40 ` Jason Gunthorpe
2020-07-20 19:56 ` Ralph Campbell
2020-07-20 19:56 ` Ralph Campbell
2020-07-20 19:56 ` Ralph Campbell
2020-07-13 17:21 ` [PATCH v2 4/5] nouveau/svm: use the new migration invalidation Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-13 17:21 ` [PATCH v2 5/5] mm/hmm/test: " Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-13 17:21 ` Ralph Campbell
2020-07-20 18:41 ` [PATCH v2 0/5] mm/migrate: avoid device private invalidations Jason Gunthorpe
2020-07-20 18:41 ` Jason Gunthorpe
2020-07-20 18:41 ` Jason Gunthorpe
2020-07-20 19:58 ` Ralph Campbell [this message]
2020-07-20 19:58 ` Ralph Campbell
2020-07-20 19:58 ` Ralph Campbell
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=dd6ffaeb-df26-99e1-f6c5-bbe3e4153f04@nvidia.com \
--to=rcampbell@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=bharata@linux.ibm.com \
--cc=bskeggs@redhat.com \
--cc=hch@lst.de \
--cc=jgg@mellanox.com \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=shuah@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.