nbd-vram - Linux में NVIDIA GPU VRAM को swap space के रूप में इस्तेमाल करने वाला टूल

 (github.com/c0dejedi)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • nbd-vram एक छोटा daemon है जो Linux में NVIDIA GPU की खाली पड़ी VRAM को high-priority swap space के रूप में इस्तेमाल करने देता है
  • soldered memory होने के कारण upgrade मुश्किल हो और integrated AMD/ATI GPU डिस्प्ले आउटपुट संभाल रहा हो, ऐसे hybrid graphics laptop में यह खाली NVIDIA VRAM का उपयोग memory pressure कम करने के लिए करता है
  • टेस्ट environment AMD/ATI + RTX 3070 Laptop, RAM 16GB, VRAM 8GB, NVIDIA driver 580.159.03, kernel 6.17, Pop!_OS है, और इसमें 7GB VRAM को swap के लिए आवंटित करके zram·SSD swap सहित लगभग 46GB addressable memory बनाई गई
  • काम करने का क्रम यह है कि पहले RAM भरती है, फिर VRAM PCIe के जरिए overflow हुए pages को absorb करती है, उसके बाद zram CPU पर compression करता है, और अंत में SSD इस्तेमाल होता है
  • daemon, CUDA driver API से VRAM allocate करता है, Unix socket पर NBD(Network Block Device) protocol के जरिए block device उपलब्ध कराता है, और kernel का built-in nbd driver इसे /dev/nbdX के रूप में expose करता है ताकि इसे सामान्य swap device की तरह इस्तेमाल किया जा सके
  • data path इस तरह है: kernel swap subsystem → /dev/nbdX → nbd kernel driver → Unix socket → nbd-vram daemon → cuMemcpyHtoD/DtoH → GPU VRAM
  • अलग kernel module या NVIDIA kernel symbol की जरूरत नहीं होती, इसलिए kernel·driver update के बाद भी बिना rebuild के इसे बनाए रखा जा सकता है
  • NVIDIA P2P API तरीका consumer GeForce GPU पर इसलिए विफल होता है क्योंकि nvidia_p2p_get_pages_persistent EINVAL लौटाता है, और BAR1 direct ioremap_wc तरीका भी लगभग 16MiB display framebuffer के बाहर के क्षेत्र को पढ़ने पर 0 लौटाता है
  • CUDA copy path cuMemcpyHtoD और cuMemcpyDtoH बिना किसी विशेष permission के CUDA GPU पर काम करते हैं, इसलिए NBD access, P2P·BAR1 सीमाओं को bypass कर देता है
  • आवश्यकताएँ हैं: CUDA support वाला NVIDIA GPU, libcuda.so.1 के साथ NVIDIA driver, Linux kernel 3.0+ का nbd module, nbd-client, gcc, make; CUDA toolkit की जरूरत नहीं है
  • installation के बाद vram-swap-nbd systemd service boot पर अपने-आप चलती है, और /etc/systemd/system/vram-swap-nbd.service में VRAM_SETUP_SIZE_MB और VRAM_SWAP_PRIORITY से इस्तेमाल होने वाली VRAM की अधिकतम सीमा और swap priority समायोजित की जा सकती है
  • daemon पहले मांगे गए VRAM size को आज़माता है, और अगर GPU memory कम पड़े तो 512MiB के step में घटाकर allocate करता है, इसलिए VRAM_SETUP_SIZE_MB अनिवार्य size नहीं बल्कि upper limit की तरह काम करता है
  • power-aware management चालू होने पर AC power हटने या battery threshold से नीचे जाने पर service अपने-आप रुक जाती है, और power वापस आने पर फिर शुरू हो जाती है; manual systemctl stop को यह override नहीं करती
  • RTX 3070 Laptop benchmark में sequential throughput और sustained random I/O में NVMe तेज़ है, लेकिन 4K read 1 request/sec latency में VRAM औसतन 335us के साथ NVMe के 9.05ms से 27 गुना तेज़ है
  • यह MIT license के तहत उपलब्ध है, और repository में smoke test के लिए test-nbd.sh, पूरे partition की जाँच के लिए test-fill.sh, तथा throughput·IOPS·latency benchmark scripts भी शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की टिप्पणियाँ

  • अगर इसे CUDA के ज़रिए फ़ाइल स्टोरेज या माउंट की तरह हैंडल किया जाए तो ओवरहेड बड़ा होगा, इसलिए BAR का उपयोग करने पर throughput या IOPS में साफ़ सुधार हो सकता है

  • अगर यह soldered memory वाले, बिना upgrade path वाले लैपटॉप के लिए है, तो “महंगी RAM से भी महंगी RAM में swap क्यों करें?” वाला शुरुआती सवाल समझ में आ जाता है
    उपयोग-क्षेत्र सीमित लगता है, लेकिन SSD पर swap होने वाली स्थिति में खाली पड़ी 8GB VRAM का इस्तेमाल ज़रूरत पड़ने पर अच्छा विचार है

    • एक और वजह यह है कि VRAM मौजूद होती है, लेकिन हमेशा उपयोग में नहीं रहती
      उदाहरण के लिए अगर आपने gaming के लिए GPU खरीदा है, तो जब आप गेम नहीं खेल रहे हों तब desktop rendering को 16GB VRAM की ज़रूरत नहीं होती, तो उसे किसी और काम में क्यों न लिया जाए
      हाँ, इसके लिए यह मानना पड़ेगा कि गेम शुरू होने पर सिस्टम swap के लिए इस्तेमाल हो रही VRAM को खाली कर सके; असल में यह संभव है या नहीं, यह जानना दिलचस्प होगा
    • क्या VRAM को सच में सामान्य RAM की तरह इस्तेमाल किया जा सकता है? उदाहरण के लिए अगर आपके पास 16GB RAM module है और GPU में 16GB VRAM है, तो क्या सिस्टम को 32GB RAM दिखाया जा सकता है, और उसका असर क्या होगा?
    • पहले ज़माने में इसे RAM disk कहा जाता था, और Atari ST बहुत तेज़ हो जाता था
      1980 के दशक के मध्य से 1990 के दशक के मध्य तक UK में आम Amstrad PCW में अधिकतम 512kB RAM इस्तेमाल की जा सकती थी, और उसका काफ़ी बड़ा हिस्सा RAM disk बनाया जा सकता था
      Turbo Pascal से compile करना भी बहुत तेज़ हो जाता था :-)

  • विचार अच्छा है, लेकिन यहाँ कुछ बहुत गड़बड़ लग रहा है
    RTX 3070 Laptop पर sequential throughput लगभग 1.3 GB/s बताया गया है, जबकि यह RTX 3070 chip PCIe 4.0 x16 है, तो 64GB/s आना चाहिए, और 8GB GDDR6 खुद 448GB/s है
    NVMe drive पर swap करना शायद दोगुना तेज़ होगा, लेकिन latency ज़्यादा होगी

    • PCIe 4.0 x16 की bandwidth प्रति दिशा 32 GB/s है, और यहाँ का implementation वह तरीका नहीं है जिसे high performance के लिए चुना जाए
      benchmark भी ZRAM के साथ चलाया गया, और ZRAM swap में लिखने से पहले pages को compress करता है. उसका performance overhead ठीक-ठीक कितना है, पता नहीं, लेकिन काफ़ी बड़ा हो सकता है
      सबसे पहले, user-space program उस nbd driver पर टिका है जो धीमा होने के लिए जाना जाता है, और GPU में ट्रांसफ़र से पहले user-space bounce buffer भी इस्तेमाल करता है. जब kernel को page swap करना हो, तो पहले उसे user-space में exposed buffer में copy करना पड़ता है, फिर user-space program दोबारा जागता है, CUDA operation issue करता है, और उस page को device memory में copy करता है
      nbd high queue depth या adjacent access merging को भी अच्छी तरह support नहीं करता. अगर kernel बिना merge किए बहुत सारे 4K page swap issue करे, तो सिर्फ़ 4 GB/s संभालने के लिए भी प्रति सेकंड कम-से-कम दस लाख kernel/user-space context switch चाहिए होंगे. 64 GB/s की तो बात ही छोड़िए. यह सिर्फ़ NBD हिस्से की बात है, NVIDIA driver की जटिलता को छोड़कर
      PCIe बहुत सारा data ले जा सकता है, लेकिन पूरी bandwidth के करीब पहुँचने के लिए लंबे page list वाले DMA engine का इस्तेमाल करना पड़ता है. PCIe पर हर 4K page के लिए transfer setup करने से bus पूरी तरह saturate नहीं होगी
      NVMe पर swap का path बहुत optimized है. swapper page list सीधे NVMe driver को submit कर सकता है, और controller RAM से सीधे DMA के ज़रिए fetch कर लेता है, इसलिए CPU side copy या context switch बिल्कुल नहीं होता
      अगर इसे ublk driver पर ले जाया जाए, तो शायद user-space bounce buffer से बचा जा सके, और कई write queue के साथ CUDA copy को parallel setup करके सुधार भी संभव हो सकता है
    • NVMe पर swap करने से NAND के PE cycle भी खर्च होते हैं, जिससे समय के साथ wear होता है
      RAM या VRAM इस्तेमाल करने से degrade नहीं होती

  • मेरे development machine में 32GB RAM है और 32GB VRAM भी, जो AI model न चलाने पर ज़्यादातर खाली पड़ी रहती है, इसलिए यह विचार इतना बुरा नहीं लगता

    • यह कुछ वैसा है जैसे pcmasterrace वाला शरीर — ऊपर से बहुत भारी, नीचे से बहुत पतला

  • सोच रहा हूँ backpressure को यह कैसे संभालता है. अगर VRAM swap space के रूप में इस्तेमाल हो रही हो और उसी दौरान VRAM allocation की मांग आ जाए तो क्या होगा?
    X11 में buffers पहले से allocate रहते हैं, इसलिए स्थिति उतनी बुरी नहीं, लेकिन Wayland में allocation कहीं ज़्यादा dynamic है, तो VRAM कम पड़ने पर पूरा desktop आसानी से crash हो सकता है
    Hyprland+llama-server+KVM के साथ कंप्यूटर switch करते समय VRAM रिलीज़ न हो पाने से मैंने ऐसे crash कई बार झेले हैं

  • user level पर swap device बनाना पहले से ही classic unsolved problems में से एक रहा है
    अगर daemon को किसी page को swap in करना हो, लेकिन उस page को swap in करने से पहले daemon के अपने pages को ही swap in करना पड़े, तो क्या होगा?
    कम-से-कम microkernel के कभी काम न करने के कारणों में इस तरह की चर्चा होती रही है. यहाँ समाधान क्या है, यह साफ़ नहीं है

    • daemon इतना समझदार हो कि उसे पता हो उसके अपने pages कौन-से हैं, और वह उन्हें swap out होने से रोक दे
      Linux kernel भी अपने text pages को swap out होने से रोकता है, इसलिए समाधान पहले से मौजूद है, और microkernel design पर यह लागू क्यों नहीं हो सकता, समझ नहीं आता
    • सामान्य सिद्धांत यह है कि जो paging में शामिल है, वह खुद pageable नहीं होना चाहिए
      उस daemon की पूरी memory pin कर देने से यह समस्या मामूली बन जाती है

  • याद है, पहले Linux के MTD/phram driver से कुछ ऐसा ही किया था: https://wiki.archlinux.org/title/Swap_on_video_RAM
    बस यह नहीं पता कि आज भी वह कितना प्रासंगिक है, क्योंकि DRM के साथ इसका interaction कैसा है और VRAM का कुछ हिस्सा reserve कैसे किया जाता है, यह स्पष्ट नहीं है. xorg.conf से limit सुझाने वाला तरीका अब शायद काफ़ी पुराना पड़ चुका है
    उस page पर OpenCL के ऊपर implement किया गया एक FUSE filesystem भी है: https://github.com/Overv/vramfs
    संभव है यह ज़्यादा compatible हो

    • पहले mtd के ज़रिए 8MB video memory map करके इस्तेमाल करता था, और उससे उन... X11 drivers को build करने में मदद मिलती थी
      पुरानी यादें ताज़ा हो गईं

  • Windows पर भी कुछ साल पहले ऐसा कुछ देखा था
    वह एक experimental proof-of-concept driver था जो NVIDIA card की VRAM से RAM drive बनाने देता था, और sequential access अपेक्षा के अनुसार तेज़ था, लेकिन random access में अभी बहुत सुधार की गुंजाइश थी
    GpuRamDrive GPU RAM से backed virtual drive बनाता है: https://github.com/prsyahmi/GpuRamDrive
    AMD support fork: https://github.com/brzz/GpuRamDrive/

  • मिलता-जुलता है, लेकिन यह OpenCL API का उपयोग करता है इसलिए AMD पर भी चलता है
    हालाँकि AMD driver में काफ़ी bugs हैं, इसलिए “चलता है” की परिभाषा चाहिए: https://libguestfs.org/nbdkit-vram-plugin.1.html

  • समझ नहीं आता कि 32GB RAM वाले Apple Silicon Mac में, जब 20GB अभी भी unused/“free” है, तब भी swap file क्यों इस्तेमाल होती है या बनाई भी जाती है
    Linux के swapoff -a जैसी आसान command से swap file को पूरी तरह disable क्यों नहीं किया जा सकता?
    अगर मकसद जानबूझकर SSD की उम्र घटाना नहीं है, तो यह थोड़ा मूर्खतापूर्ण लगता है
    अच्छा होता अगर GUI में swap file बंद करने की system setting होती, और Apple मौजूदा system settings/layout के इस “phase” को भी आखिर छोड़ दे. दशकों पुराने preference panels की तुलना में यह अब भी शब्दों का सलाद जैसा लगता है
    #Apple #Feedback #swapfile

    • paging system का सिद्धांत यह है कि main memory, secondary storage का cache है
      “available memory” की धारणा भी आदर्श रूप में “ऐसी memory जिसे दूसरे काम के लिए जल्दी reclaim किया जा सके” के ज़्यादा करीब है
      कुछ स्थितियों में anonymous memory को main memory में बनाए रखने से बेहतर होता है कि cached file contents उसकी जगह ले लें