Thread (26 messages) 26 messages, 7 authors, 2021-07-30

Re: [PATCH v3 0/8] Support DEVICE_GENERIC memory in migrate_vma_*

From: Felix Kuehling <felix.kuehling@amd.com>
Date: 2021-06-24 15:08:38
Also in: amd-gfx, dri-devel, linux-mm, linux-xfs

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:
quoted
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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help