Jaderné noviny - 23. 6. 2016: Virtuálně mapované jaderné zásobníky (diskuse)

[Michal Kubeček]

Současný vývojový kernel má označení 4.7-rc7, vydán byl 19. června.

Já vím, že si čtenáři stěžovali, že jsou překlady pozadu, ale realitu byste předbíhat nemuseli. :-) Verze 4.7-rc7 ještě nevyšla, 19.6. vyšla -rc4.

[ByCzech]

Dohnat a předehnat!

[pc2005]

Zásobník se nachází v přímo mapované paměti jádra, takže musí být fyzicky souvislý. Tento požadavek může být problematický sám o sobě, protože jak dochází k fragmentaci paměti, může být nalezení dvou nebo čtyř fyzicky souvislých stránek složité.

To je teda navrhovali dost špatně :-/. Resp se to jeví jako pěknej hack, když to při přechodu na vícestránkové stacky neudělali robustně.

V důsledku neexistuje přímá indikace v případě, že k přetečení dojde.

Znamenám si, pokud někdy vymyslím CPU architekturu, tak přidám range check registry .

Paměť mapovaná do rozsahu vmalloc má jedno specifické omezení: nedá se jednoduše použít pro I/O s přímým přístupem k paměti (DMA). To proto, že I/O očekává paměť fyzicky souvislou, a proto, že funkce mapování virtuálních adres na fyzické neočekávají adresy v tomto rozsahu.

Jo když byli v Intel tak hloupí (nebo naopak marketingově vychcaní), že při přechodu na PCI neudělali nějakou scatter gather DMA engine jednotku ...

[petr_p]

Mám dojem, že IOMMU zavedená kvůli izolaci PCI zařízení při virtualizaci řeší nesouvislou fyzickou paměť. Nebo by alespoň logické bylo, aby to uměla, když stejně musí všechny přístupy do paměti překládat.

[pc2005]

To bylo k DMA nebo ke stacku? Stack by měl poslouchat normální MMU v procesoru. U DMA by ta IOMMU musela mít ještě něco, co přenese stránky paměti bez použití CPU. Ale i tak by prostě Intel zaspal, Naposled, kdy se DMA na x86 hodila bylo na ISA sběrnici a ani můj c2d žádnej takovej engine nemá.

[petr_p]

To bylo k DMA. IOMMU se uplatní i při DMA, protože IOMMU je věc mimo CPU. A drobná poznámka v DMA-API-HOWTO o CONFIG_NEED_SG_DMA_LENGTH mi dává naději, že s IOMMU a DMA lze používat scatter-gather.

[pc2005]

Jo aha. Já to myslel tak, že kdyby už v době PCI udělali samostatnej řadič, co umí scatter-gather, tak by šla IOMMU nejdřív dělat softwarově a pak by to už jen šlo cestou vývoje do hardwarové IOMMU akcelerace. V reálu šla cesta tak, že pokud člověk nechtěl používat CPU na přenos dat, tak si musel pořídit PCI device s busmasterem a samozřejmě každej výrobce si naimplementoval vlastní šířky přenášených polí apod.

[Atom321]

Jo když byli v Intel tak hloupí (nebo naopak marketingově vychcaní), že při přechodu na PCI neudělali nějakou scatter gather DMA engine jednotku ...

Ono nejde jen o Intel, ale i o ostatní architektury, na kterých Linux běhá.

[pc2005]

No právě ono to vypadá, že všichni ostatní to DMA mají (to se tu tuším jednou Ponkrác rozčiloval, že DMA umí každej, ale bez ní to je ta pravá inženýřina). Minimálně to měly Sun workstationy se SPARCem (jedna PCI karta od nich to vyžaduje, bez DMA enginu to jede přes PCI tak maximálně 1MBps). Dokonce i blbej microblaze může mít DMA engine .

[Atom321]

No DMA řadič většinou mají, ale velmi často jen jednoduchý, který umí pracovat jen se souvislými bloky fyzické paměti. Jádro má API na alokaci souvislých DMA bufferů, které to řeší. Jenže některé drivery spoléhaly na to, že paměť na stacku je také fyzicky souvislá a lze ji tak použít pro DMA buffer přímo.

[pc2005]

Hele u microblaze nevím, ale tam je to softcore, takže si to můžeš vždycky patchnout. U ARMu (OMAP3) se dají DMA požadavky řetězit a můžeš dělat snad i šílenosti jako jedna strana inkrementace a druhá dekrementace (to si možná pletu s novějšíma, ale určitě se inkrementovat třeba o 100 bajtů).

Jednoduchej (ale univerzální) copypaste měla PXA27x XScale a to je 12 let zpátky.

[Atom321]

No, zrovna EDMA na OMAPech je poměrně mocný nástroj. Je to stavěné na přenos dat z kamery do DSP a z DSP do framebufferu. Dají se s tím dělat psí kusy - např. rotovat bitmapy a podobně. Myslím, že dokonce podporuje virtuální adresaci jako takovou. Takže tam by určitě problém nebyl.

I tak by s DMA scatter/gather musely umět pracovat ty drivery, což nejspíš neumějí, protože k tomu doteď nebyl důvod.

[little.owl]

Podpora scatter/gather na PCIe je zalezitost vlastnich zarizeni a limitace je spise na Linux DMA API, ktere predpoklada souvislou fyzickou pamet.

[pc2005]

PCI(e) bus master není to samý co DMA engine. Bus master je na kartě, kdežto DMA engine je samostatná jednotka někde v čipsetu (v "jazyce" PCI by tomu odpovídala karta se dvěma PCI rozhraníma s busmasterem a nějakým jednoduchým bufferem - pozor velmi špatná analogie ).

Jde o to, že některé PCI zařízení busmaster nemají (není povinný) a tak do nich musíš hezky cpát data byte po bajtu přes CPU.

[little.owl]

Ja netvrdim, ze je to DMA engine, ale ze nabizi scatter/gather mode. DMA bylo soucasti ISA sbernice a po zkusenostech se to uz do PCI(e) nedalo - bus-mastering je mnohem lepsi reseni - vas pozadavek pro nejaky centralni DMA engine nema moc smysl.

[pc2005]

Mám dva x86 "počítače" spojené PCI mostem. Ten sice umí na obou stranách bus master, ale jen jako reakci na zápis/čtení z druhé strany. Veškeré přenosy musí tedy obstarávat CPU. Na SPARCu ale byla speciální jednotka, která umožňovala zahájit přenos z jedné adresy na jinou. Tam tedy jenom stačilo, aby CPU nastartoval přenos v té jednotce.

Neříkám, že by to musela být ISA implementace (to fakt ne, omezení na 0-16MB v RAM apod.), ale i na blbé memcpy by se taková jednotka hodila.

[little.owl]

Mám dva x86 "počítače" spojené PCI mostem. Ten sice umí na obou stranách bus master, ale jen jako reakci na zápis/čtení z druhé strany.

A v cem je problem? Na jedne strane poslu blok dat, na strane druhe prijmu, pres PCI bus-master DMA.

Veškeré přenosy musí tedy obstarávat CPU.

Snad jen kontrolovat, vetsina toku by mela jit mimo CPU.

Volani po dedikovanem DMA zarizeni je ozivovani konceptu, ktery se moc neosvedcil mimo specialisovane architektury. Prosadil se koncept, kdy sbernice bude podporovat pouze zakladni (non-)posted transakce, nebude mit definovanou topologii, ale zakladni bloky jako bridge a svym designem nebude hazet klacky pod nohy implementaci radice, od velmi primitivniho a levneho az i po nejaky obsahujici treba pokrocily DMA engine provadejici konverzi dat on-the-fly. Nad PCIe protokolem lze jednoduse implementovat genericke specialisovana rozsireni pro radice jako NVM Express pro PCIe SSD disky, ktere uz maji explicitni podporu pro scatter/gatter prenosy. V dobe, kdy brzy bude standard 8-16 CPU jader, je lepsi alokovat cast jedno jadra pro pokryti situace jednoducheho PCIe radice, a vyuzit MSI-X a memory-mapped IO k implementaci scatter/gather prenosu s prijatelnym overheadem.

Intel nabizi Intel QuickData na Xeon, coz je v podstate DMA engine. Nakolik to funguje netusim, ale souvisejici I/O Acceleration Technology (IOAT) byla z kernelu po sedmi letech vyhozena, nebot to zpusobovalo korupci pameti, takze historie se nam zase tak nejak opakuje.

Na SPARCu ale byla speciální jednotka, která umožňovala zahájit přenos z jedné adresy na jinou.

Tim mate na mysli konkretne co? Sbus, ktery byl nakonec nahrazen PCI? IMHO, SPARC DMA engine standardne pripojeny na Sbus neumel scatter/gather transfery.

Neříkám, že by to musela být ISA implementace (to fakt ne, omezení na 0-16MB v RAM apod.), ale i na blbé memcpy by se taková jednotka hodila.

A proc? Na male bloky dat je optimalizovane memcpy (treba nad AVX2) vetsinou lepsi nez DMA, uz jen proto ze operuje nad cim dale vetsimi CPU cache a ne nad pomalou DDR a nemusite se starat o cache coherence. Velke datove transfery jsou zalezitosti I/O na PCIe se zabudovanym radicem, a pokud nekdo potrebuje kopirovat velke bloky v pameti beze zmeny pres CPU, ma nejspise hloupe navrzenou aplikaci.

[pc2005]

A v cem je problem? Na jedne strane poslu blok dat, na strane druhe prijmu, pres PCI bus-master DMA.

Ten bridge je jen pasivní překlad z jedné domény do druhé (žádné sdružování do bloků apod.). Procesor neumí vygenerovat přenos bloku dat, ale zapisuje jen slovo po slově. Takže místo třeba 1x 256B bloku se provede 64x 32bit transakcí. Transakce 32bit slova po slově dosáhne tak stěží 2MBps dohromady v obou směrech. S univerzálním DMA enginem by se posílaly bloky bezproblému.

Snad jen kontrolovat, vetsina toku by mela jit mimo CPU.

To by byla DMA, když je to memcpy na x86, tak je to prostě kopírovací smyčka, kde to dělá CPU.

Volani po dedikovanem DMA zarizeni ...

Tak ten DMA engine by klidně mohl bejt v čipsetu jako PCI device. Vtip je prostě v tom, že jediné zařízení, co neumí blokovej busmaster je CPU (s vyjímkami jako cache linka do RAM, ale to vlastně není PCI).

Jj I/OAT, ale to je až v Xeonech, PCI bylo už v posledních 486 (SiS496/7 umí obsáhnout celej 4GB prostor).

Tim mate na mysli konkretne co? Sbus, ktery byl nakonec nahrazen PCI? IMHO, SPARC DMA engine standardne pripojeny na Sbus neumel scatter/gather transfery.

Hele tak to přesně nevím, ale ta karta je SunPCI II a měla do toho Sunu přidávat podporu pro Windowsy . Je to normální PCI 64bit karta a funguje teda i na x86 kompu. Akorát ty přenosy jsou příšerně pomalý, pokud se maj posílat třeba komunikační pakety. Povrchně jsem zkoumal původní SPARC platformu a prej to mělo DMA engine, co prostě mohla říct sem do RAM zkopíruj 64kB dat z tohodle PCI regionu. To, že by to fungovalo i na PCI je pak logický předpoklad, aby ta karta vůbec mohla efektivně komunikovat.

A proc? Na male bloky dat je optimalizovane memcpy (treba nad AVX2) vetsinou lepsi nez DMA, uz jen proto ze operuje nad cim dale vetsimi CPU cache a ne nad pomalou DDR a nemusite se starat o cache coherence.

To je pravda, ale neznamená to, že to nejde udělat lépe.

Mě teda přišlo, že se třeba pakety kopírujou v kernelu všude možně.

a pokud nekdo potrebuje kopirovat velke bloky v pameti beze zmeny pres CPU, ma nejspise hloupe navrzenou aplikaci.

No právě, že s inteligentním DMA přenosem můžeš třeba transponovat matici (proto furt nadávám na PXA Xscale, protože tam ani nešlo pootočit obraz na LCD o 90 stupňů - leda pixel po pixelu přes CPU).

[little.owl]

Ten bridge je jen pasivní překlad z jedné domény do druhé (žádné sdružování do bloků apod.). Procesor neumí vygenerovat přenos bloku dat, ale zapisuje jen slovo po slově. Takže místo třeba 1x 256B bloku se provede 64x 32bit transakcí. Transakce 32bit slova po slově dosáhne tak stěží 2MBps dohromady v obou směrech.

Vam stale nedochazi, ze problem je na strane PCI zarizeni, ktere potrebuje prenaset velke bloky dat a pritom podporuje jen 32 bitovy prenos, ktery ma velkou rezii, a implementuje zlomek toho, co je mozne implementovat nad PCI a co zvlada i nejhloupejsi sitova karta za 10 dolaru. Soude podle toho, co popisujete, je lepsi propojit vase PC kabelem pres dve sitove karty a vas PCI bridge odnest do recyklacniho centra.

S univerzálním DMA enginem by se posílaly bloky bezproblému.

CPU jadro je velmi univerzalni, flexibilni a plne programovatelny DMA engine a jejich pocet v soucasnych procesorech utesene roste.

Mě teda přišlo, že se třeba pakety kopírujou v kernelu všude možně.

A mne prijde, ze se kopirovani snazi omezit.

No právě, že s inteligentním DMA přenosem můžeš třeba transponovat matici

Psal jsem:

Volani po dedikovanem DMA zarizeni je ozivovani konceptu, ktery se moc neosvedcil mimo specialisovane architektury.

a transponovat matici behem DMA prenosu je pomerne specializovana vec a opet bych to na PC hodil na AVX, pripadne na GPU. Pouzivam programovatelne DMA enginy na TI platformach jiz deset let, takze tusim co to prinasi v praxi, a proto jsem spise proti tomu, aby se to davalo do univerzalniho PC jako genericky blok. To ze ani Intel neni schopen v kernelu udrzovat dlohodobe plne funkcni podporu I/OAT me obavy jen potvrzuje.

[petr_p]

Možná vás bude zajímat, že poslední dobou se chystají obecné FPGA bloky s přístupem do paměti. Poslední generace PowerPC serverů je už má, prototypy už mají výrobci Aarch64 serverů, lidi od x86 a MIPS zatím mají jenom řeči (resp. Intel koupil Alteru). V případě Power8 FPGA tahá data přes PCIe skrze zvláštní řadič, který zajišťuje koherenci mezí cachí CPU a cachí FPGU.

[little.owl]

To muze byt cesta, pouzivam roky FPGA PCI karty, na nichz lze implementovat i onen DMA engine a je dosti mozne, ze i soucasne GPU pujdou podobnym smerem. Reseni na PC vidim v generickem, flexibilnim a programovatelnem HW, ktery pak softwarove pokryje i specializovane pouziti, nikoliv ve specializovane HW jednotce.

[pc2005]

Jo to půjde, akorát FPGA je pomalý a v implementacích může nastat taková nekompatibilita, že to neušéfuje ani UEFI :-P.

[little.owl]

Pomale mi to neprijde, jen ponekud drahe a programovat je lze i v OpenCL, viz. treba Nallatech.

[pc2005]

Maximální rychlost sekvenční logiky je zhruba 500MHz, ale složitější věci maj i třeba jen 150MHz max.

[little.owl]

Za prve, je to jiz o neco rychlejsi. Za druhe, sila FPGA je v parallelnich algoritmech, na sekvencni algoritmy pouziji procesor. Za treti odkazovane karty zalozene na Alter Aria 10 integruji dual-core ARM Cortex-A9, ktery sdili radic pameti (DDR4) s FPGA, takze se limituji problemy s cache a lze to vhodne kombinovat.

[pc2005]

Je to rychlejší, ale sběrnici taktovanou třeba na 1066 MHz to stejně nejspíš nedá :-/. Sekvenční logikou myslím HDL pojem sekvenční/kombinační (prostě něco co má zpětné vazby).

[pc2005]

Vam stale nedochazi, ze problem je na strane PCI zarizeni, ktere potrebuje prenaset velke bloky dat a pritom podporuje jen 32 bitovy prenos, ktery ma velkou rezii, a implementuje zlomek toho, co je mozne implementovat nad PCI a co zvlada i nejhloupejsi sitova karta za 10 dolaru.

Tak já bych taky radši, kdyby měl ten bridge vlastní buffer a busmasteroval si bloky. Ale už to, že existuje (a další verze implementoval dokonce Intel) ukazuje, že má PCI nedostatky.

Soude podle toho, co popisujete, je lepsi propojit vase PC kabelem pres dve sitove karty a vas PCI bridge odnest do recyklacniho centra.

Přesně tak, taky to bylo ze začátku o řád rychlejší . Bohužel ten bridge je velmi rozšířený a je skoro všude.

CPU jadro je velmi univerzalni, flexibilni a plne programovatelny DMA engine a jejich pocet v soucasnych procesorech utesene roste.

Bohužel stále ne na x86 desktopu/notebooku .

A mne prijde, ze se kopirovani snazi omezit.

Nedostatečně .

a transponovat matici behem DMA prenosu je pomerne specializovana vec a opet bych to na PC hodil na AVX, pripadne na GPU.

V případě RAM→GPU je AVX plýtvání procesorového času. A GPU s rotací bitmapy je lepší mít rozdělenou na dva modulární HW.

[majvan]

Mozem vediet, ako PCI specifikacia podporuje scatter gather prenosy?

[little.owl]

Specifikace PCI scatter/gather prenosy primo nepodporuje, ale umoznuje je s prijatelnym overheadem implementovat.