[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211115193026.27568-1-alex.sierra@amd.com>
Date: Mon, 15 Nov 2021 13:30:17 -0600
From: Alex Sierra <alex.sierra@....com>
To: <akpm@...ux-foundation.org>, <Felix.Kuehling@....com>,
<linux-mm@...ck.org>, <rcampbell@...dia.com>,
<linux-ext4@...r.kernel.org>, <linux-xfs@...r.kernel.org>
CC: <amd-gfx@...ts.freedesktop.org>, <dri-devel@...ts.freedesktop.org>,
<hch@....de>, <jgg@...dia.com>, <jglisse@...hat.com>,
<apopple@...dia.com>, <willy@...radead.org>
Subject: [PATCH v1 0/9] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping
This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
owned by a device that can be mapped into CPU page tables like
MEMORY_DEVICE_GENERIC and can also be migrated like
MEMORY_DEVICE_PRIVATE.
Christoph, the suggestion to incorporate Ralph Campbell’s refcount
cleanup patch into our hardware page migration patchset originally came
from you, but it proved impractical to do things in that order because
the refcount cleanup introduced a bug with wide ranging structural
implications. Instead, we amended Ralph’s patch so that it could be
applied after merging the migration work. As we saw from the recent
discussion, merging the refcount work is going to take some time and
cooperation between multiple development groups, while the migration
work is ready now and is needed now. So we propose to merge this
patchset first and continue to work with Ralph and others to merge the
refcount cleanup separately, when it is ready.
This patch series is mostly self-contained except for a few places where
it needs to update other subsystems to handle the new memory type.
System stability and performance are not affected according to our
ongoing testing, including xfstests.
How it works: The system BIOS advertises the GPU device memory
(aka VRAM) as SPM (special purpose memory) in the UEFI system address
map.
The amdgpu driver registers the memory with devmap as
MEMORY_DEVICE_COHERENT using devm_memremap_pages. The initial user for
this hardware page migration capability is the Frontier supercomputer
project. This functionality is not AMD-specific. We expect other GPU
vendors to find this functionality useful, and possibly other hardware
types in the future.
Our test nodes in the lab are similar to the Frontier configuration,
with .5 TB of system memory plus 256 GB of device memory split across
4 GPUs, all in a single coherent address space. Page migration is
expected to improve application efficiency significantly. We will
report empirical results as they become available.
We extended hmm_test to cover migration of MEMORY_DEVICE_COHERENT. This
patch set builds on HMM and our SVM memory manager already merged in
5.15.
Alex Sierra (9):
mm: add zone device coherent type memory support
mm: add device coherent vma selection for memory migration
drm/amdkfd: add SPM support for SVM
drm/amdkfd: coherent type as sys mem on migration to ram
lib: test_hmm add ioctl to get zone device type
lib: test_hmm add module param for zone device type
lib: add support for device coherent type in test_hmm
tools: update hmm-test to support device coherent type
tools: update test_hmm script to support SP config
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 34 ++-
include/linux/memremap.h | 8 +
include/linux/migrate.h | 1 +
include/linux/mm.h | 9 +
lib/test_hmm.c | 270 +++++++++++++++++------
lib/test_hmm_uapi.h | 21 +-
mm/memcontrol.c | 6 +-
mm/memory-failure.c | 6 +-
mm/memremap.c | 5 +-
mm/migrate.c | 30 ++-
tools/testing/selftests/vm/hmm-tests.c | 156 +++++++++++--
tools/testing/selftests/vm/test_hmm.sh | 20 +-
12 files changed, 446 insertions(+), 120 deletions(-)
--
2.32.0
Powered by blists - more mailing lists