From: Felix Kuehling <felix.kuehling@amd.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Theodore Ts'o <tytso@mit.edu>, Alex Sierra <alex.sierra@amd.com>,
akpm@linux-foundation.org, linux-mm@kvack.org,
rcampbell@nvidia.com, linux-ext4@vger.kernel.org,
linux-xfs@vger.kernel.org, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, jgg@nvidia.com,
jglisse@redhat.com
Subject: Re: [PATCH v3 0/8] Support DEVICE_GENERIC memory in migrate_vma_*
Date: Thu, 24 Jun 2021 11:08:30 -0400 [thread overview]
Message-ID: <3fd9dea5-6166-a92a-f9cb-e53f5590b2f8@amd.com> (raw)
In-Reply-To: <20210624053048.GB25004@lst.de>
Am 2021-06-24 um 1:30 a.m. schrieb Christoph Hellwig:
> On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
>> For the reference counting changes we could use the dax driver with hmem
>> and use efi_fake_mem on the kernel command line to create some
>> DEVICE_GENERIC pages. I'm open to suggestions for good user mode tests to
>> exercise dax functionality on this type of memory.
>>
>> For the migration helper changes we could modify or parametrize
>> lib/hmm_test.c to create DEVICE_GENERIC pages instead of DEVICE_PRIVATE.
>> Then run tools/testing/selftests/vm/hmm-tests.c.
> We'll also need a real in-tree user of the enhanced DEVICE_GENERIC memory.
> So while the refcounting cleanups early in the series are something I'd
> really like to see upstream as soon as everything is sorted out, the
> actual bits that can't only be used by your updated driver should wait
> for that.
The driver changes are pretty much ready to go.
But we have a bit of a chicken-egg problem because those changes likely
go through different trees. The GPU driver changes will go through
drm-next, but we can't merge them there until our dependencies have been
merged there from upstream. Unless we protect everything with some #ifdef.
Regards,
Felix
WARNING: multiple messages have this Message-ID (diff)
From: Felix Kuehling <felix.kuehling@amd.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Alex Sierra <alex.sierra@amd.com>,
rcampbell@nvidia.com, Theodore Ts'o <tytso@mit.edu>,
amd-gfx@lists.freedesktop.org, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, jglisse@redhat.com,
dri-devel@lists.freedesktop.org, jgg@nvidia.com,
akpm@linux-foundation.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH v3 0/8] Support DEVICE_GENERIC memory in migrate_vma_*
Date: Thu, 24 Jun 2021 11:08:30 -0400 [thread overview]
Message-ID: <3fd9dea5-6166-a92a-f9cb-e53f5590b2f8@amd.com> (raw)
In-Reply-To: <20210624053048.GB25004@lst.de>
Am 2021-06-24 um 1:30 a.m. schrieb Christoph Hellwig:
> On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
>> For the reference counting changes we could use the dax driver with hmem
>> and use efi_fake_mem on the kernel command line to create some
>> DEVICE_GENERIC pages. I'm open to suggestions for good user mode tests to
>> exercise dax functionality on this type of memory.
>>
>> For the migration helper changes we could modify or parametrize
>> lib/hmm_test.c to create DEVICE_GENERIC pages instead of DEVICE_PRIVATE.
>> Then run tools/testing/selftests/vm/hmm-tests.c.
> We'll also need a real in-tree user of the enhanced DEVICE_GENERIC memory.
> So while the refcounting cleanups early in the series are something I'd
> really like to see upstream as soon as everything is sorted out, the
> actual bits that can't only be used by your updated driver should wait
> for that.
The driver changes are pretty much ready to go.
But we have a bit of a chicken-egg problem because those changes likely
go through different trees. The GPU driver changes will go through
drm-next, but we can't merge them there until our dependencies have been
merged there from upstream. Unless we protect everything with some #ifdef.
Regards,
Felix
WARNING: multiple messages have this Message-ID (diff)
From: Felix Kuehling <felix.kuehling@amd.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Alex Sierra <alex.sierra@amd.com>,
rcampbell@nvidia.com, Theodore Ts'o <tytso@mit.edu>,
amd-gfx@lists.freedesktop.org, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, jglisse@redhat.com,
dri-devel@lists.freedesktop.org, jgg@nvidia.com,
akpm@linux-foundation.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH v3 0/8] Support DEVICE_GENERIC memory in migrate_vma_*
Date: Thu, 24 Jun 2021 11:08:30 -0400 [thread overview]
Message-ID: <3fd9dea5-6166-a92a-f9cb-e53f5590b2f8@amd.com> (raw)
In-Reply-To: <20210624053048.GB25004@lst.de>
Am 2021-06-24 um 1:30 a.m. schrieb Christoph Hellwig:
> On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
>> For the reference counting changes we could use the dax driver with hmem
>> and use efi_fake_mem on the kernel command line to create some
>> DEVICE_GENERIC pages. I'm open to suggestions for good user mode tests to
>> exercise dax functionality on this type of memory.
>>
>> For the migration helper changes we could modify or parametrize
>> lib/hmm_test.c to create DEVICE_GENERIC pages instead of DEVICE_PRIVATE.
>> Then run tools/testing/selftests/vm/hmm-tests.c.
> We'll also need a real in-tree user of the enhanced DEVICE_GENERIC memory.
> So while the refcounting cleanups early in the series are something I'd
> really like to see upstream as soon as everything is sorted out, the
> actual bits that can't only be used by your updated driver should wait
> for that.
The driver changes are pretty much ready to go.
But we have a bit of a chicken-egg problem because those changes likely
go through different trees. The GPU driver changes will go through
drm-next, but we can't merge them there until our dependencies have been
merged there from upstream. Unless we protect everything with some #ifdef.
Regards,
Felix
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2021-06-24 15:08 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 15:16 [PATCH v3 0/8] Support DEVICE_GENERIC memory in migrate_vma_* Alex Sierra
2021-06-17 15:16 ` Alex Sierra
2021-06-17 15:16 ` Alex Sierra
2021-06-17 15:16 ` [PATCH v3 1/8] ext4/xfs: add page refcount helper Alex Sierra
2021-06-17 15:16 ` Alex Sierra
2021-06-17 15:16 ` Alex Sierra
2021-06-17 16:11 ` Darrick J. Wong
2021-06-17 16:11 ` Darrick J. Wong
2021-06-17 16:11 ` Darrick J. Wong
2021-06-17 23:52 ` Dave Chinner
2021-06-17 23:52 ` Dave Chinner
2021-06-17 23:52 ` Dave Chinner
2021-06-19 16:14 ` Sierra Guiza, Alejandro (Alex)
2021-06-19 16:14 ` Sierra Guiza, Alejandro (Alex)
2021-06-19 16:14 ` Sierra Guiza, Alejandro (Alex)
2021-06-19 18:31 ` Alex Sierra
2021-06-19 18:31 ` Alex Sierra
2021-06-19 18:31 ` Alex Sierra
2021-06-17 15:16 ` [PATCH v3 2/8] mm: remove extra ZONE_DEVICE struct page refcount Alex Sierra
2021-06-17 15:16 ` Alex Sierra
2021-06-17 15:16 ` Alex Sierra
2021-06-17 19:16 ` Ralph Campbell
2021-06-17 19:16 ` Ralph Campbell
2021-06-17 19:16 ` Ralph Campbell
2021-06-28 16:46 ` Felix Kuehling
2021-06-28 16:46 ` Felix Kuehling
2021-06-28 16:46 ` Felix Kuehling
2021-06-30 0:23 ` Ralph Campbell
2021-06-30 0:23 ` Ralph Campbell
2021-06-30 0:23 ` Ralph Campbell
2021-06-17 15:17 ` [PATCH v3 3/8] kernel: resource: lookup_resource as exported symbol Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` [PATCH v3 4/8] drm/amdkfd: add SPM support for SVM Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` [PATCH v3 5/8] drm/amdkfd: generic type as sys mem on migration to ram Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` [PATCH v3 6/8] include/linux/mm.h: helpers to check zone device generic type Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` [PATCH v3 7/8] mm: add generic type support to migrate_vma helpers Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` [PATCH v3 8/8] mm: call pgmap->ops->page_free for DEVICE_GENERIC pages Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:17 ` Alex Sierra
2021-06-17 15:56 ` [PATCH v3 0/8] Support DEVICE_GENERIC memory in migrate_vma_* Sierra Guiza, Alejandro (Alex)
2021-06-17 15:56 ` Sierra Guiza, Alejandro (Alex)
2021-06-17 15:56 ` Sierra Guiza, Alejandro (Alex)
2021-06-20 14:14 ` Theodore Ts'o
2021-06-20 14:14 ` Theodore Ts'o
2021-06-20 14:14 ` Theodore Ts'o
2021-06-23 21:49 ` Felix Kuehling
2021-06-23 21:49 ` Felix Kuehling
2021-06-23 21:49 ` Felix Kuehling
2021-06-24 5:30 ` Christoph Hellwig
2021-06-24 5:30 ` Christoph Hellwig
2021-06-24 15:08 ` Felix Kuehling [this message]
2021-06-24 15:08 ` Felix Kuehling
2021-06-24 15:08 ` Felix Kuehling
2021-07-16 15:07 ` Theodore Y. Ts'o
2021-07-16 15:07 ` Theodore Y. Ts'o
2021-07-16 15:07 ` Theodore Y. Ts'o
2021-07-16 22:14 ` Felix Kuehling
2021-07-16 22:14 ` Felix Kuehling
2021-07-16 22:14 ` Felix Kuehling
2021-07-17 19:54 ` Sierra Guiza, Alejandro (Alex)
2021-07-17 19:54 ` Sierra Guiza, Alejandro (Alex)
2021-07-17 19:54 ` Sierra Guiza, Alejandro (Alex)
2021-07-23 22:46 ` Sierra Guiza, Alejandro (Alex)
2021-07-23 22:46 ` Sierra Guiza, Alejandro (Alex)
2021-07-23 22:46 ` Sierra Guiza, Alejandro (Alex)
2021-07-30 19:02 ` Felix Kuehling
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=3fd9dea5-6166-a92a-f9cb-e53f5590b2f8@amd.com \
--to=felix.kuehling@amd.com \
--cc=akpm@linux-foundation.org \
--cc=alex.sierra@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=jgg@nvidia.com \
--cc=jglisse@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=rcampbell@nvidia.com \
--cc=tytso@mit.edu \
/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.