Vlákno názorů k článku
Fedora 44 ještě 32bit x86 neodstaví, diskuse byla velmi výživná od RDa - On to problem je - programatori jsou lini...

On to problem je - programatori jsou lini programovat spravne multiplatformne.

Tady nejde i486, tam nejde i586, hentam nejde 32bit.. protoze linost nejlinejsi je pouzit int, a problem sverit prekladaci, at z toho neco vymysli. Stejne jako pagesize.. 4K je mantra a trvalo dve dekady nez nekdo zjistil ze existuje neco jineho.

Uz jen takova cicovina jako ze size_t je 32-bit tady a 64-bit tam - kdyz se jedna o system, ktery muze bezt na 32 i 64 bitech. To melo byt definovano vzdy jako max(possible).. a ne ze budu delat magicke #define zaklinadla aby se v libc zpristupnila gnu extension pro dlouhe soubory.

Jestli nekde je malinkost potreba, at definuji treba PURE32, a pak si muzeme stavet mini veci se starymi cpu v aplikacich co nepouzivaji nic vic.

A alokovat souvislou fyzickou pamet (na zadost userspace) pokud vim taky porad nejde.. - a proto nvme firmware update dela cunarny ze v tom i samotni autori maj gulas... ale budem se hadat o zariznuti 32-bitu a vyhazovani neperspektivniho kodu.

Tak s tím int, ono lepší typy v stdint.h přišly až v C99, do té doby to bylo o mraku #ifdef-u
Takze se to tahne.

Alokacia suvislej pamate moze byt problem, podobny ako kedysi potreba alokovat pod fyzickymi 16M alebo 4G: jednoducho nemusi byt ziadny blok volny v pozadovanej velkosti. Alebo moze, podla toho, ako skoro po boote pride poziadavka. Potom jedna a ta ista vec raz funguje a raz nefunguje a pouzivatel je z toho blbec.

GPU to riesia tak, ze maju svoju vlastnu pamat a tu si namapuju do pamatoveho priestoru procesov. Takze je suvisla, akurat vsetko co ide do nej tecie potom cez PCIe. Takze ja by som skor uvital vseobecne dostupny GPUDirect (priamy transfer medzi NVMe a GPU, resp. inymi PCIe zariadeniami)

Ale tak OS muze s beznymi strankami delat co chce - treba je swapovat nebo persouvat - a defragmentovat pametovy prostor.

Manipulace je zakazana pouze pro specialni (zamcene) stranky, ktere uz nekdo aktivoval pro DMA. Ale techto stranek je objemem par MB, nikdy ne tolik aby to zaplnilo byt jen spodnich 4GiB.

Desktopove GPU to zacali resit az nedavno (skrze resizable BAR), coz je dalsi WTF - proc takova technologie vubec vznikla, kdyz serverove GPU/Akceleratory meli mapovanou celou pamet - a jediny pozadavek na system bylo "Enable above 4G" - zas jenom umela marketingova segmentace a potreba vnucovat lidem "novy" hw.

GPU direct je nyni dostupnejsi (samozrejme jak kde), ale nedavno jsem si prave hral s userspace nvme driverem, ktery pak dokaze pouzivat gpu buffery (samozrejme - zas CUDA only).

V OS (asi vsech) celkove chybi podpora pro mmap-reference pro file io - napr. jak delam zarizeni ktere komprimuje video a pada to z nejakeho "akcelaratoru na pcie", tak by me mega pomohlo ze bych mohl do souboru zapsat nejake hlavicky z OS (systemove/apli­kacni ram), ale zbytek obsahu si nechat stahnout z one akceleracni karty primo. Pak by totiz mohl byt CPU pripojen jen uzkym hrdlem k nejakemu PCIe switchi.

Jine featury co by se hodili - spojovani souboru (jen upravou alokacnich tabulek) - generuji stream, ale na konci je potreba pridat index - radeji na pocatek souboru (protoze pak se nedokoncena kopie da pouzit, kdezto s indexem na konci je potreba ho slozite rekonstruovat)

V OS (asi vsech) celkove chybi podpora pro mmap-reference pro file io - napr. jak delam zarizeni ktere komprimuje video a pada to z nejakeho "akcelaratoru na pcie", tak by me mega pomohlo ze bych mohl do souboru zapsat nejake hlavicky z OS (systemove/apli­kacni ram), ale zbytek obsahu si nechat stahnout z one akceleracni karty primo.

Todle umi Linux uz od 2.6.17. Proste udelam mmap na zarizeni preprezentujici dany HW, pripadne na genericky devmem a pak zavolam vmsplice()

1. 7. 2025, 15:13 editováno autorem komentáře

> Jine featury co by se hodili - spojovani souboru (jen upravou alokacnich tabulek)

ioctl_ficlone­range(2) -- len treba mat filesystem, ktory to podporuje (xfs, btrfs).

No vida.. a ted si to nekdo prosim vemte na semestralku/ba­kalarku/diplom­ku - pro vfat/exfat/ext4 :D

(ale tohle je klonovani bloku - jako kopie bez kopie, v CoW svete .. ja chci spis neco jako move - transplantovat jeden soubor do druheho.. prvni pak o dany range treba prijde)

1. 7. 2025, 15:52 editováno autorem komentáře

Manipulace je zakazana pouze pro specialni (zamcene) stranky, ktere uz nekdo aktivoval pro DMA. Ale techto stranek je objemem par MB, nikdy ne tolik aby to zaplnilo byt jen spodnich 4GiB.

S tím si dovolím nesouhlasit. Např. vědecké kamery připojené přes PCIe běžně hrnou data přes DMA přímo do user-space paměti, v mém případě naprosté minimum 2-4 GB, hlavně zero-copy, což mnohdy nestačí ani na 1s záznamu. Zákazníci běžně žádají nastreamování desítek GB do RAM, aby nemuseli ukládat na disk (čti jako: mám 128GB RAM, 28GB stačí systému tak do zbytku chci data). Někteří mají 128GB, jiní i 256GB RAM, taky ne zřídka mají 2 nebo i 4 kamery...

Desktopove GPU to zacali resit az nedavno (skrze resizable BAR), coz je dalsi WTF - proc takova technologie vubec vznikla, kdyz serverove GPU/Akceleratory meli mapovanou celou pamet - a jediny pozadavek na system bylo "Enable above 4G" - zas jenom umela marketingova segmentace a potreba vnucovat lidem "novy" hw.

S tíhle naopak souhlasím. Bylo by fajn si namapovat většinu GPU paměti pro DMA z kamery a nad daty hned spustit CUDA processing bez zdouhavého kopírování tam a zpět. GPUDirect RDMA je fajn, ale dost omezuje výběr HW pokud člověku nestačí 256MB DMA buffer. Navíc vývojáři jádra stále utahují šrouby a je jen otázkou času, kdy propojení GPL a nVidia driveru přestane fungovat...

To jste to ale nepochopil :)

Kontinualni region fyzicke pameti je opravdu orisek v OS alokatoru, ale chapu ze se jim do toho nechce - protoze by to pak nekdo zacal nedejboze vyuzivat. Takze se omezuje na obskurni HW, ktery opravdu vyzaduje CMA.

Vsichni ostatni dokazali v HW implementovat Scatter-Gather (SGDMA), tj. na libovolne adresy, jenom si to sebou nese vetsi naroky - jak hw tak provozni - ten seznam adres musite dodat do zarizeni a vznikaji vyssi latence pripadne to muze hladovatet - takze ve vysledku je to reseni pomalejsi. Tohle jsme prave resili taky a vyresili to celkem slusne - nase PCIe jadro taky umi SG a nema ty extra latence jako konkurencni jadra.

Pouzivame to taky do kamer.. a samozrejme to dokaze zapisovat i do zarizeni vedle, nejen do systemove pameti. Staci kdyz dodate patricny pointer (resp. seznam fyzickych stranek). A zda ho ziskate dostatecne veliky - zavisi opravdu na vyberu grafiky. V dnesni dobe s RDMA pres Ethernet se ta svolnost vyrobcu grafik snad trocha pohla, a neni to az tak umele omezovany jako kdysi.

Btw i s 256M poolem by se dalo zit, pokud vase drivery ke gpu zvladnou nejake mensi mapovane oblasti prehazovat rychleji. Pokud totiz uvazuji o fronte na 4 snimky z duvodu minimalni latence (prakticke minimum je u nas ale 3, provozni pak 2 - ale to potrebujete opravdu predikovatelny skoro RT system), tak buffer pro frame muze byt 64MB - nevim co za rozliseni pouzivate.. ale typicky mate mensi snimek nez 32MP/16bit resp 42MP/12bit. To bych spis cekal ze to GPU neda po vykonove strance RT zpracovani takoveho objemu dat, nez aby byl problem s DMA do nej, byt pres mensi okno.

Programátoři dělají buď to, za co je někdo platí nebo to, co je baví. Obávám se, že to, co požadujete se v mnoha ohledech nepřkrývá s ani jednou z těch množin.