GPU SVM Section

GPU SVM 합의 설계 원칙

`migrate_to_ram` 경로는 migration PTE, page reference, page locking 같은 core MM 개념에만 의존합니다. Hardware interaction용 lock 외에 driver-specific lock을 두지 않습니다. Core MM race를 막기 위해 driver lock을 새로 만드는 것은 불필요하고 대체로 잘못된 접근입니다.

과거 `do_swap_page`가 faulting page를 lock하도록 고치기 전, `migrate_to_ram`의 driver-exclusive lock은 충분한 thread가 faulting page를 읽을 때 안정적인 livelock을 만들었습니다. Migration은 일부 page만 성공하는 partial migration을 허용하며 faulting page만 migration이 보장됩니다. Mixed migration은 lock이 아니라 retry loop로 처리합니다.

Eviction은 GPU memory를 비우기 위해 virtual address 없이 GPU의 data를 CPU 쪽으로 migration하는 작업입니다. Virtual memory structure·lock이 아니라 physical memory structure·lock만 봅니다. CPU virtual address는 언제든 바뀌지만 physical page는 안정적이기 때문입니다. GPU virtual address가 필요한 GPU page-table invalidation은 그 주소를 가진 notifier가 처리합니다.

GPU fault 쪽에서는 `mmap_read`를 요구하는 core MM function 주변에서만 이 lock을 사용하고 가능하면 GPU SVM layer에서만 획득합니다. GPU page-table lock과 MMU notifier range lock 아래의 race는 큰 retry loop로 처리합니다.

Concurrent eviction이나 `migrate_to_ram` race를 fault handler가 추가 lock으로 막지 않습니다. 가능한 예외는 최초 VRAM migration 동안 BO의 `dma-resv` lock을 잡는 경우입니다. 이 lock은 잘 정의되어 있고 `mmap_read` 아래에서 획득할 수 있습니다.

GPU access는 반드시 GPU memory에서 일어나야 한다는 엄격한 migration policy가 있으면 concurrent CPU access 때문에 endless retry livelock이 생길 수 있습니다. 현재 GPU SVM user인 Xe에는 이런 policy가 없지만 미래에는 추가될 수 있습니다. 해결은 driver lock보다 core MM에서 이루어지는 편이 이상적입니다.

Physical memory에서 virtual memory로 가는 backpointer는 두지 않습니다. `mremap()`은 address 변경을 driver에 알리지 않고 invalidation notifier만 보내므로 이런 pointer는 유효하지 않습니다. Physical backpointer인 `page->zone_device_data`는 allocation부터 page free까지 안정적으로 유지해야 하며 concurrent user와 안전하게 갱신하기는 page free 전에는 매우 어렵습니다.

GPU page-table notifier lock은 range tree, range의 page-valid state, page-table entry, MMU notifier seqno tracking만 보호합니다. Wider notifier 때문에 단순 seqno 대신 valid state를 다룹니다. 이 lock은 모든 race를 막는 global lock이 아니며 나머지 race는 큰 retry로 처리합니다.

.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)

===============
GPU SVM Section
===============

Agreed upon design principles
=============================

* migrate_to_ram path
        * Rely only on core MM concepts (migration PTEs, page references, and
          page locking).
        * No driver specific locks other than locks for hardware interaction in
          this path. These are not required and generally a bad idea to
          invent driver defined locks to seal core MM races.
        * An example of a driver-specific lock causing issues occurred before
          fixing do_swap_page to lock the faulting page. A driver-exclusive lock
          in migrate_to_ram produced a stable livelock if enough threads read
          the faulting page.
        * Partial migration is supported (i.e., a subset of pages attempting to
          migrate can actually migrate, with only the faulting page guaranteed
          to migrate).
        * Driver handles mixed migrations via retry loops rather than locking.
* Eviction
        * Eviction is defined as migrating data from the GPU back to the
          CPU without a virtual address to free up GPU memory.
        * Only looking at physical memory data structures and locks as opposed to
          looking at virtual memory data structures and locks.
        * No looking at mm/vma structs or relying on those being locked.
        * The rationale for the above two points is that CPU virtual addresses
          can change at any moment, while the physical pages remain stable.
        * GPU page table invalidation, which requires a GPU virtual address, is
          handled via the notifier that has access to the GPU virtual address.
* GPU fault side
        * mmap_read only used around core MM functions which require this lock
          and should strive to take mmap_read lock only in GPU SVM layer.
        * Big retry loop to handle all races with the mmu notifier under the gpu
          pagetable locks/mmu notifier range lock/whatever we end up calling
          those.
        * Races (especially against concurrent eviction or migrate_to_ram)
          should not be handled on the fault side by trying to hold locks;
          rather, they should be handled using retry loops. One possible
          exception is holding a BO's dma-resv lock during the initial migration
          to VRAM, as this is a well-defined lock that can be taken underneath
          the mmap_read lock.
        * One possible issue with the above approach is if a driver has a strict
          migration policy requiring GPU access to occur in GPU memory.
          Concurrent CPU access could cause a livelock due to endless retries.
          While no current user (Xe) of GPU SVM has such a policy, it is likely
          to be added in the future. Ideally, this should be resolved on the
          core-MM side rather than through a driver-side lock.
* Physical memory to virtual backpointer
        * This does not work, as no pointers from physical memory to virtual
          memory should exist. mremap() is an example of the core MM updating
          the virtual address without notifying the driver of address
          change rather the driver only receiving the invalidation notifier.
        * The physical memory backpointer (page->zone_device_data) should remain
          stable from allocation to page free. Safely updating this against a
          concurrent user would be very difficult unless the page is free.
* GPU pagetable locking
        * Notifier lock only protects range tree, pages valid state for a range
          (rather than seqno due to wider notifiers), pagetable entries, and
          mmu notifier seqno tracking, it is not a global lock to protect
          against races.
        * All races handled with big retry as mentioned above.

Overview of baseline design
===========================

.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
   :doc: Overview

.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
   :doc: Locking

.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
   :doc: Partial Unmapping of Ranges

Baseline drm_gpusvm design

Baseline design은 `drivers/gpu/drm/drm_gpusvm.c`의 네 `kernel-doc` block으로 구성됩니다. `Overview`는 전체 모델, `Locking`은 동기화 계약, `Partial Unmapping of Ranges`는 일부 range 해제, `Examples`는 사용 예를 설명합니다.

.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
   :doc: Examples

Overview of drm_pagemap design
==============================

.. kernel-doc:: drivers/gpu/drm/drm_pagemap.c
   :doc: Overview

.. kernel-doc:: drivers/gpu/drm/drm_pagemap.c
   :doc: Migration

drm_pagemap design

`drm_pagemap` 설계는 `drivers/gpu/drm/drm_pagemap.c`의 `Overview`와 `Migration` `kernel-doc` block에서 설명합니다.

Possible future design features
===============================

* Concurrent GPU faults
        * CPU faults are concurrent so makes sense to have concurrent GPU
          faults.
        * Should be possible with fined grained locking in the driver GPU
          fault handler.
        * No expected GPU SVM changes required.

가능한 미래 기능

CPU fault처럼 GPU fault도 concurrent하게 처리하는 기능을 고려합니다. Driver GPU fault handler의 fine-grained locking으로 가능하며 GPU SVM 자체 변경은 필요하지 않을 것으로 예상합니다.

System page와 device page가 섞인 range는 필요하면 `drm_gpusvm_get_pages`에 비교적 쉽게 추가할 수 있습니다. Multi-GPU 지원은 진행 중이며 GPU SVM 최초 landing 뒤 patch가 예정되어 있고, 가능하면 GPU SVM 변경을 최소화합니다.

Notifier 속도를 높이기 위해 range 대신 radix tree를 사용할 수 있습니다. Compound device page는 migrate-device layer의 비싼 core MM call 횟수를 줄여 NVIDIA·AMD·Intel이 공통으로 지적한 performance bottleneck을 완화할 수 있습니다.

Intel hardware에서는 4K DMA mapping이 migration 성능을 해치므로 higher-order 2M DMA mapping이 도움이 될 수 있습니다.

그 밖에 GPU SVM 위의 공통 userptr 구현, driver-side `madvise`와 migration policy, Leon/NVIDIA의 pending dma-mapping API 변경 반영이 후보입니다.

* Ranges with mixed system and device pages
        * Can be added if required to drm_gpusvm_get_pages fairly easily.
* Multi-GPU support
        * Work in progress and patches expected after initially landing on GPU
          SVM.
        * Ideally can be done with little to no changes to GPU SVM.
* Drop ranges in favor of radix tree
        * May be desirable for faster notifiers.
* Compound device pages
        * Nvidia, AMD, and Intel all have agreed expensive core MM functions in
          migrate device layer are a performance bottleneck, having compound
          device pages should help increase performance by reducing the number
          of these expensive calls.
* Higher order dma mapping for migration
        * 4k dma mapping adversely affects migration performance on Intel
          hardware, higher order (2M) dma mapping should help here.
* Build common userptr implementation on top of GPU SVM
* Driver side madvise implementation and migration policies
* Pull in pending dma-mapping API changes from Leon / Nvidia when these land