nbd-vram - Alat untuk menggunakan VRAM GPU NVIDIA sebagai ruang swap di Linux

• nbd-vram adalah daemon kecil yang memungkinkan VRAM NVIDIA yang sedang tidak digunakan dipakai sebagai ruang swap berprioritas tinggi di Linux
• Pada laptop grafis hibrida dengan memori tersolder yang sulit di-upgrade dan GPU AMD/ATI terintegrasi yang menangani output layar, alat ini memanfaatkan VRAM NVIDIA yang menganggur untuk membantu meredakan tekanan memori
• Lingkungan pengujian adalah AMD/ATI + RTX 3070 Laptop, RAM 16GB, VRAM 8GB, driver NVIDIA 580.159.03, kernel 6.17, dan Pop!_OS; dengan mengalokasikan 7GB VRAM sebagai swap lalu digabungkan dengan zram dan swap SSD, terbentuk sekitar 46GB memori yang dapat dialamatkan
• Urutan kerjanya adalah RAM terisi lebih dulu, lalu VRAM menyerap halaman yang meluap melalui PCIe, setelah itu zram melakukan kompresi di CPU, dan terakhir SSD digunakan
• Daemon mengalokasikan VRAM melalui CUDA driver API, lalu menyediakan perangkat blok lewat protokol NBD (Network Block Device) di atas Unix socket; driver nbd bawaan kernel mengeksposnya sebagai /dev/nbdX sehingga bisa digunakan seperti perangkat swap biasa
• Jalur datanya adalah kernel swap subsystem → /dev/nbdX → nbd kernel driver → Unix socket → nbd-vram daemon → cuMemcpyHtoD/DtoH → GPU VRAM
• Karena tidak memerlukan modul kernel terpisah atau simbol kernel NVIDIA, alat ini bisa tetap dipakai setelah pembaruan kernel maupun driver tanpa perlu rebuild
• Pendekatan NVIDIA P2P API gagal pada GPU GeForce konsumen karena nvidia_p2p_get_pages_persistent mengembalikan EINVAL, dan pendekatan ioremap_wc langsung ke BAR1 juga gagal karena pembacaan area di luar framebuffer tampilan sekitar 16MiB mengembalikan 0
• Jalur salin CUDA cuMemcpyHtoD dan cuMemcpyDtoH bekerja pada GPU CUDA tanpa izin khusus, sehingga akses NBD dapat melewati batasan P2P dan BAR1
• Kebutuhannya adalah GPU NVIDIA yang mendukung CUDA, driver NVIDIA dengan libcuda.so.1, modul nbd pada Linux kernel 3.0+, nbd-client, gcc, dan make; CUDA toolkit tidak diperlukan
• Setelah instalasi, layanan systemd vram-swap-nbd akan berjalan otomatis saat boot, dan batas atas VRAM yang dipakai serta prioritas swap dapat disesuaikan melalui VRAM_SETUP_SIZE_MB dan VRAM_SWAP_PRIORITY di /etc/systemd/system/vram-swap-nbd.service
• Daemon terlebih dahulu mencoba ukuran VRAM yang diminta, lalu jika memori GPU tidak cukup akan menguranginya dalam satuan 512MiB hingga berhasil dialokasikan, sehingga VRAM_SETUP_SIZE_MB berfungsi sebagai batas atas, bukan ukuran wajib
• Jika manajemen berbasis status daya diaktifkan, layanan akan otomatis berhenti saat daya AC dilepas atau baterai turun di bawah ambang batas, lalu berjalan kembali saat daya pulih; systemctl stop manual tidak akan ditimpa
• Dalam benchmark RTX 3070 Laptop, throughput sekuensial dan random I/O berkelanjutan lebih cepat di NVMe, tetapi latensi baca 4K pada 1 request/sec di VRAM rata-rata 335us, 27 kali lebih cepat daripada NVMe yang mencatat 9.05ms
• Dirilis dengan lisensi MIT, dan repositorinya juga menyediakan test-nbd.sh untuk smoke test, test-fill.sh untuk pemeriksaan partisi penuh, serta skrip benchmark untuk throughput, IOPS, dan latensi

[GN⁺]

Komentar Hacker News

• Jika diperlakukan seperti penyimpanan file atau mount melalui CUDA, overhead-nya besar, jadi sepertinya dengan memakai BAR throughput atau IOPS bisa meningkat cukup jelas

• Jika penjelasannya adalah ini untuk laptop dengan memori solder tanpa jalur upgrade, maka itu menjawab pertanyaan spontan tentang kenapa melakukan swap dari RAM yang mahal ke RAM yang lebih mahal
  Kegunaannya memang tampak sempit, tetapi dalam situasi swap ke SSD, memakai 8GB VRAM yang sedang menganggur adalah ide yang bagus saat dibutuhkan

  • Alasan lain adalah, ada kasus di mana VRAM ada tetapi tidak selalu dipakai
    Misalnya jika membeli GPU untuk bermain game, saat tidak bermain rasanya tidak perlu 16GB VRAM untuk rendering desktop, jadi kenapa tidak dipakai untuk hal lain
    Hanya saja, ini mengandaikan sistem bisa melepaskan VRAM yang dipakai sebagai swap saat game dimulai, dan saya penasaran apakah itu benar-benar memungkinkan
  • Apakah VRAM benar-benar bisa dipakai seperti RAM biasa? Misalnya kalau ada modul RAM 16GB dan GPU dengan 16GB VRAM, bisakah sistem dibuat menampilkan 32GB RAM, dan apa dampaknya?
  • Dulu hal seperti ini disebut RAM disk, dan Atari ST jadi sangat cepat
    Pada Amstrad PCW yang umum di Inggris dari pertengahan 80-an hingga pertengahan 90-an, kita bisa memakai hingga 512kB RAM, dan bagian yang cukup besar bisa dijadikan RAM disk
    Saat kompilasi dengan Turbo Pascal juga jadi sangat cepat :-)

• Idenya bagus, tetapi tampaknya ada sesuatu yang sangat keliru di sini
  Disebutkan throughput sekuensial sekitar 1.3 GB/s pada RTX 3070 Laptop, padahal chip RTX 3070 ini memakai PCIe 4.0 x16 sehingga seharusnya mencapai 64GB/s, dan 8GB GDDR6-nya sendiri punya 448GB/s
  Swap ke drive NVMe mungkin dua kali lebih cepat, tetapi latensinya akan lebih tinggi

  • PCIe 4.0 x16 adalah 32 GB/s per arah, dan cara implementasi di sini bukanlah pendekatan yang dipilih jika menginginkan performa tinggi
    Benchmark juga dijalankan dengan ZRAM, dan ZRAM mengompresi halaman sebelum ditulis ke swap. Saya tidak tahu persis berapa overhead performanya, tetapi kemungkinan cukup besar
    Pertama, ini terikat pada driver nbd yang dikenal lambat sebagai program ruang pengguna, dan juga memakai bounce buffer di ruang pengguna sebelum dikirim ke GPU. Jika kernel harus men-swap halaman, ia terlebih dahulu menyalinnya ke buffer yang terekspos ke ruang pengguna, lalu program ruang pengguna bangun lagi dan mengeluarkan operasi CUDA untuk menyalin halaman itu ke memori perangkat
    nbd juga tidak terlalu mendukung queue depth tinggi atau penggabungan akses yang berdekatan. Jika kernel mengeluarkan banyak swap halaman 4K tanpa penggabungan, bahkan untuk memproses 4 GB/s saja dibutuhkan setidaknya sekitar satu juta context switch kernel/ruang pengguna per detik. Apalagi 64 GB/s. Dan ini baru melihat bagian NBD saja, belum termasuk kompleksitas driver NVIDIA
    PCIe memang bisa memindahkan banyak data, tetapi untuk mendekati bandwidth penuhnya perlu memakai DMA engine dengan daftar halaman yang panjang. Jika pengaturan transfer di PCIe dilakukan per halaman 4K, bus tidak akan bisa dijenuhkan sepenuhnya
    Jalur swap ke NVMe sangat dioptimalkan. Swapper bisa langsung menyerahkan daftar halaman ke driver NVMe, dan kontroler mengambilnya langsung dari RAM lewat DMA sehingga tidak ada penyalinan di sisi CPU maupun context switch sama sekali
    Jika dipindahkan ke driver ublk, mungkin bisa menghindari bounce buffer ruang pengguna, dan mungkin juga memperbaiki keadaan dengan menyiapkan penyalinan CUDA paralel lewat beberapa write queue
  • Swap ke NVMe juga menghabiskan siklus PE NAND sehingga akan aus seiring waktu
    RAM maupun VRAM tidak mengalami degradasi hanya karena dipakai

• Di mesin pengembangan saya ada 32GB RAM dan 32GB VRAM yang sebagian besar menganggur saat tidak menjalankan model AI, jadi ide ini tidak terlalu buruk

  • Ini terasa seperti gaya pcmasterrace: badan atas besar sekali tapi kakinya kurus kering

• Saya penasaran bagaimana backpressure ditangani. Apa yang terjadi jika ada permintaan alokasi VRAM saat VRAM sedang dipakai sebagai ruang swap?
  Di X11, buffer dialokasikan sebelumnya jadi tidak terlalu buruk, tetapi di Wayland alokasinya jauh lebih dinamis, jadi kalau VRAM habis seluruh desktop bisa mudah mati
  Saya pernah beberapa kali mengalami tabrakan seperti ini saat berpindah komputer dengan Hyprland+llama-server+KVM karena gagal membebaskan VRAM

• Membuat perangkat swap di tingkat pengguna sudah lama menjadi salah satu masalah klasik yang tidak terselesaikan
  Jika daemon ingin melakukan swap-in sebuah halaman, tetapi untuk melakukan swap-in halaman itu justru halaman milik daemon itu sendiri harus di-swap-in lebih dulu, lalu bagaimana?
  Setidaknya pernah ada diskusi seperti ini sebagai alasan kenapa mikrokernel tidak akan pernah benar-benar bekerja. Saya kurang tahu solusi di sini apa

  • Daemon itu cukup pintar untuk tahu halaman mana miliknya, lalu mencegah halaman-halaman itu di-swap-out
    Kernel Linux juga mencegah halaman teks miliknya sendiri di-swap-out, jadi solusinya sudah ada, dan saya tidak melihat alasan kenapa itu tidak bisa diterapkan pada desain mikrokernel
  • Prinsip umumnya adalah apa pun yang terlibat dalam paging tidak boleh ikut di-page
    Kalau seluruh memori daemon itu dikunci, masalah ini jadi selesai secara sepele

• Saya ingat dulu pernah melakukan hal serupa dengan driver MTD/phram Linux: https://wiki.archlinux.org/title/Swap_on_video_RAM
  Hanya saja saya tidak tahu apakah ini masih relevan sekarang, karena saya tidak tahu bagaimana interaksinya dengan DRM dan bagaimana penanganan reservasi sebagian VRAM dilakukan. Pendekatan yang mengusulkan pembatasan lewat xorg.conf kemungkinan sekarang sudah cukup kuno
  Di halaman itu juga ada filesystem FUSE yang diimplementasikan di atas OpenCL: https://github.com/Overv/vramfs
  Ini mungkin lebih kompatibel

  • Dulu saya biasa memetakan 8MB memori video lewat mtd, dan itu membantu membangun driver-driver X11 itu...
    Jadi nostalgia

• Saya juga pernah melihat sesuatu yang mirip di Windows beberapa tahun lalu
  Itu adalah driver proof-of-concept eksperimental yang memungkinkan pembuatan RAM drive dari VRAM kartu NVIDIA, dan akses sekuensialnya cepat seperti yang diduga, tetapi akses acaknya masih banyak ruang untuk perbaikan
  GpuRamDrive membuat drive virtual yang ditopang oleh RAM GPU: https://github.com/prsyahmi/GpuRamDrive
  Fork dengan dukungan AMD: https://github.com/brzz/GpuRamDrive/

• Mirip, tetapi memakai OpenCL API sehingga juga berjalan di AMD
  Hanya saja driver AMD cukup penuh bug, jadi perlu definisi dulu tentang apa arti “berjalan”: https://libguestfs.org/nbdkit-vram-plugin.1.html

• Saya tidak mengerti kenapa Apple Silicon Mac dengan RAM 32GB masih memakai atau bahkan membuat file swap padahal 20GB masih belum dipakai/"free"
  Kenapa tidak ada perintah sederhana seperti swapoff -a di Linux untuk menonaktifkan file swap sepenuhnya?
  Jika tujuannya bukan sengaja memperpendek umur SSD, itu tampak agak bodoh
  Akan bagus kalau ada pengaturan sistem di GUI untuk mematikan file swap, dan saya juga tidak keberatan kalau Apple akhirnya membuang “tahapan” layout/pengaturan sistem yang sekarang. Dibanding panel preferensi selama puluhan tahun, ini masih terasa seperti salad kata
  #Apple #Feedback #swapfile

  • Prinsip sistem paging adalah bahwa memori utama merupakan cache bagi penyimpanan sekunder
    Konsep “memori yang tersedia” pun idealnya lebih dekat ke “memori yang bisa cepat direbut kembali untuk tujuan lain”
    Pada titik tertentu, bisa jadi lebih baik membiarkan isi file yang di-cache menempati ruang itu daripada terus mempertahankan memori anonim di memori utama