Jelentősen gyorsulhatnának a Wine-on futtatott játékok, ha beolvasztanának a Linux kernelbe egy javasolt driver-t

Wine, Proton

A CodeWeavers (veterán cég a Wine területen) alkalmazásában álló Elizabeth Figura egy RFC-t küldött különböző, Linux kernellel kapcsolatos levlistákra. Az RFC lényege az volt, hogy ha beolvasztanának a Linux kernelbe egy "Windows NT synchronization primitive driver"-t, számos ismert számítógépes játék gyorsulhatna Wine-on futtatva. A gyorsulás mértéke 21%-tól akár 600+%-ig terjedhetne:

The initial proposed patch series is a set of 32 patches while 17 patches are of the actual implementation. With these "NTSYNC" kernel driver patches there are benefits to different Windows games on Wine from 21% with Metro 2033 to as much as 678% with DiRT 3! Commonly this is helping games by upwards of 100%+ better performance.

Videoelőadás:

Részletek itt.

( bennyh | 2024. 01. 25., cs – 11:07 )

Szerkesztve: 2024. 01. 25., cs – 11:08

Ennyire tudott valamit az NT vagy éppenséggel ennyire elcs&eszett, hogy a rá optimalizált játékok egy tisztességes implementációval már nem is érzik jól magukat :D ?

In order to emulate Windows NT kernel synchronization primitives, Wine currently uses a single server process, which fields operations on those primitives via RPC from client processes.

This has historically worked well, but has turned out to be a severe performance bottleneck in heavily multithreaded applications such as modern games.

In this talk, I propose to emulate the complexity of NT synchronization primitives in a kernel driver, which according to proof-of-concept tests can improve performance up to twice the speed of current Wine.

Proof-of-concept trees are available here: https://repo.or.cz/linux/zf.git/short...

A bold amellett, hogy user space-ben volt eddig emulálva.

trey @ gépház

Az NT-ben vannak szinkronizációs primitívek, meg a Linuxban is, de nem egyformán működnek. Illetve az NT-ben van pár olyan feature, ami Linuxban nincs. De szerintem senki se állította, hogy egyik vagy másik rosszabb lenne.

A baj avval van, hogy ha Linuxon akarnak NT-t emulálni, az userspace-ben lassú, kernelben pedig lehetetlen, utóbbit akarják megoldani most.

+1

Amúgy az NT (illetve Win7, és utódai) szinkronizációs dolgai kifejezetten rosszul vannak megírva. Nagyjából 10 éve csináltam egy tesztet, ami a taszkváltás sebességét mérte. Windows-ra megírtam native-en, Win32 API-val, Linux-on meg a posix hívásokat használtam. Linux-on a hasonló kód kb. 3-szor gyorsabban futott.

Kb 15 éve olvastam arról, hogy az ütemező egy adott cpu-n mikor thread-et vált, mekkora erőforrása van a dolognak. A nyertes a SunOS volt, de ők saját (mellesleg többszálú futásra optimalizált) hardverrel mentek. Utána a Linux (talán 2x-3x akkora ideig tartott neki a context switch), míg a Windózon valami 5x-8x.

Sok minden jól van megcsinálva a Windózban, de hatalmas mennyiségű legacy kódot cipelnek magukkal, az eredeti NT kódja még mindig ott van, az oprendszer magja még mindig ugyanaz. Nem tudom, mennyit mernek a régi kódokhoz hozzányúlni, nem hiszem, hogy sokat ("don't fix what ain't broken"), az Excelnél is eléggé sokat kellett várni, mire végre 32 bites lett...

( rpsoft v | 2024. 01. 25., cs – 12:36 )

Én azt a részét nem értem (és a linkelt eredeti cikket átfutva nem is találom benne), hogy ehhez miért kellene ezt a drivert beolvasztani a kernelbe. Betölteni igen, de beolvasztani? Érkezhet a wine-nal, lefordítod, betöltöd, tudja amit kell, nem?

Olyanok akarnak, akik a zavarosban (szürke) halásznak. Pl. az NVIDIA, amelyiknek Torvalds a középső ujját mutatta. A bináris szarai + a kernel glue kódja miatt. Kapott is egy tainted flag-et a kernel, ha ilyen modul volt betöltve. NEM. Nem ez az út.

Az NVIDIA pont az elrettentő példa volt.

trey @ gépház

Okés, de nem ez volt a kérdésem, hanem hogy volt-e szó a cikkben beolvasztásról, vagy azt a fordító delirálta.

(Hint: a merge szó nem szerepel benne.)

(Mellesleg az nVidiánál és az ATInál a zavarosság oka nem az volt, hogy külön modul, olyanja van a vmware-nek is, hanem hogy volt benne egy zárt kódú blob.)

Az utolsó reakció nem az volt. Mindig csak a rossz marad meg?

https://hup.hu/cikkek/20120617/a_het_videoja_linus_az_nvidia-rol

De aztán:

https://hup.hu/cikkek/20120624/az_nvidia_mernoke_azt_kerdezi_hogy_valla…

https://hup.hu/cikkek/20140204/linus_ismet_ujjat_mutatott_az_nvidia-nak

Persze a helyzet összességében ma is inkább a középső ujj történetnek felel meg NVIDIA fronton :D

Ez egy modul, létrehoz egy /dev/ntsync devicet, amivel ioctl-eken keresztül lehet kommunikálni. Az új deviceoknak viszont kell egy egyedi ioctl azonosító, hogy más device ne használja ugyanazt véletlenül, vagy hogy az strace is okosabb lehessen ezáltal, ezért kell csak a kernel többi részét módosítani.

( kl3on v | 2024. 01. 25., cs – 13:45 )

Így első ránézésre ez ugyanaz a "probléma", mint amit a Dave Cutler (csapata) mérlegelt a Windows NT 3.1 és felfele készítésénél. 90-es évek közepe fele, szerényebb erőforrásokkal és "csak" a videodriver kérdésében, de a dilemma az volt, hogy lassú, biztonságos driver a userspace-ben, vagy gyors, kevésbé biztonságos driver a kernel spaceben. A döntés végül egy hybrid megoldás lett, de mire sikerült jól összerakni (Windows XP), addig a Windows 9x afféle átmeneti megoldás volt. A megoldás végül az lett, hogy sokminden a kernel spacebe került, a teljesítmény érdekében. Biztos van aki itt jobban ért hozzá, az a tippem, hogy ez egyébként alapvetően szembemegy a unix filozófiával. 

Érdekes az egész interjú, de jó hosszú:

https://youtu.be/xi1Lq79mLeE

Itt felmerul persze, hogy alapvetoen a mikrokernel lenne idealis, tehat driver a userspace-ben. Viszont akkor fennall, hogy a kommunikacionak a user<->kernel space kozott gyors(abb)nak kell lennie. Kerdes, hogy lehet ezt gyorsitani? Pl. ami igy egybol szembe otlik, az az, hogy a modern multicore cpu-k esetleg dedikalhatnanak egy core-t a kernel -nek, es akkor a syscall igazabol egy 'labhuzas' lenne 2 core kozott. Avagy tomorebben fogalmazva, ha a cpu-kban lenne "esetleg" tamogatas a gyors user<->kernel space kommunikaciora, akkor igazabol teljesen realis alternativava valna a mikrokernel gyakorlati alkalmazasa.

De lehet, hogy mar van is; nem kovetem a cpu instruction newbulletin-t.

Attol fugg hogy a syscall-okhoz mennyire kell context switch. Illetve mennyire lehet kitenni user space-be bizonyos kernelszintu teruleteket (lasd: VDSO). 

Raadasul ha a sync-mechanizmusokat nezzuk, ahhoz meg valojaban syscall sem kellene, ha minden szinkronizalando cucc a legalacsonyabb privilegizalasi szinten fut. Abba meg nyilvan ne menjunk bele hogy atomic rmw jellegu muveleteket trap-eken keresztul implementaljunk, ott csak nem tartunk mar :) 

Igen, erre probalok utalni, hogy ahelyett, hogy elvetjuk a mikrokernelt, mint megoldast, mert a jelen architecturak alatt kvazi hasznalhatatlan, esetleg par jol iranyzott x86 instruction-nel gyorsitani lehetne azokat a folyamatokat, amik miatt lassu a mikrokernel.

Pl. ha van egy dedikalt mag a kernelnek, akkor nem kell context switch egyaltalan. Meg ahogy irod, ha a szinkronizalasi primitivek okosabbak, akkor ahhoz se kell. Es meg sorolhatnam, igazabol valszeg megoldhato lenne kulonosebb teljesitmenyvesztes nelkul a mikrokernel, csak az nt utan nem sok menedzsernek fulik a foga, hogy megprobalja, ugy fest :O

Nem is a mikrokernel vs. nem mikrokernel dologra gondolnek igy hirtelen hanem inkabb az hogy ezek a syscall-okhoz kapcsolodo jarulekos koltsegek hogyan oszlanak el. Alapjaraton (sajnos) az x86-os ezen reszleteit annyira nem ismerem, de eleg sok risc-alike rendszerrel dolgozgatok ilyesmik kapcsan, es mar ott is rengeteg alternativa es/vagy dolog megjelenik:

  • Egyik veglet: a syscall maga egyatala nem draga, lenyegeben csak privilegizalasi szintet emel, par oraciklus alatt lemegy => ezutan marcsak a szoftveren (kernelen) mulik hogy hogyan is optimalizalja a hivast (pl hogyha a syscall nem implikal context switchet akkor az meg se tortenjen... ha impikal akkor meg kesobb mentse csak le ha elkerulhetetlen, lasd pl: blocking i/o).
  • Ha a syscall implikal valami ABI-szintu kontext switch elokeszitest (lasd: ARM), akkor ha torik-szakad draga lesz, raadasul felkesz is, szoval a szoftver is bonyolultabb lesz.
  • A context switch-ben milyen melyre megyunk le (lasd: FPU, SIMD, stb, mert ezek altalaban nem kellenek a kernel szintu folyamatokhoz, ellenben a context-nek a resze). 
  • Mi van a PMMU-val: provilegizalasi szint emeles utan azok modosithatoak, mi es/vagy mennyi eroforras kell ahhoz hogy a page table-k ugy modosuljanak (es utana ugy alljanak vissza) hogy az adott syscall vegrehajthato legyen. Es hat ez is baromira eroforrasigenyesnek tunik, foleg hogyha a jelenlegi security dolgokat nezzuk.

Es a sync mechanizmusokhoz tulajdonkeppen egyik sem kell itten fentebb :) Maramennyiben persze a memoriaterkepe ugyanaz az egyes szinkronizalando thread-eknek.

 van egy dedikalt mag a kernelnek, akkor nem kell context switch egyaltalan.

Az sajna akkor is kell, viszont az affinitas az lehet eros. Es ha megnezed a linux kernelt (pl), akkor ott is mar eleg sok szal futkoraszik. Kerdes hogy abbol melyik "a" kernel. Ebben az ertelemben azt hivnam kernelnek (azt a fizikai magot) ami a megfelelo int-et/irq-t megkapja. 

Én nagy híve vagyok a mikrokernelnek, mert szerintem elegánsabb megoldás, absztraktabb réteget nyújt a hardverkezelésnek, drivereknek, az OS alkotóelemeinek, külön fejleszthető, frissíthető a driverektől függetlenül. De teljesítményben mindenképp lassabb lesz, mert user space-ben mindenképp lesz overhead a kernellel kommunikáció felé. Az is igaz, hogy ahogy fejlődnek, gyorsulnak a hardverek, ez egyre kevésbé lesz fontos. Úgyis ma már annyi overhead van, egy csomó OS-en modulok virtualizálva futnak, meg sok minden konténerizálva, nem hinném, hogy a mikrokernel miatti overhead sokat számítana.

Mindenesetre nem véletlen, hogy a legtöbb OS a mai napig hibrid vagy makrókerneles, a mikrokernel ritkaság, csak kísérleti és beágyazott rendszereken használt, ott se gyakran, Blackberry QNX, Minix, Mach kernel, az újak közül Redox OS.

A Linux sose lesz mikrokerneles. Ezt Torvalds mindjárt az elején, a Tannenbaum-mal folytatott vitában leszögezte, meg nem fog dobni sok millió kódsort, és újrakezdeni a fejlesztést, hátha lesz nyereség rajta vagy nem.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Itt nem videódriver-ről van szó, hanem annál egy sokkal általánosabb driver-ről, ami az NT hívásokat kezeli. Ha egyszer tényleg ekkora teljesítménytöbbletet fog adni, akkor nem vitás, hogy a kernelben van a helye. Akit zavar, vagy instabilnak tartja, az kihagyja a kernel fordításából ezt, vagy modprobe.d-ben feketelistázza, és használ helyette user space emulációt. A Linux világa és architektúrája teljesen más amúgy is, máshogy épül fel, már maga a grafikus interface is (X vagy Wayland), így a Windows megkötései, meg MS programozók dilemmái nem kötik.

Továbbá a Linux nem Unix, illetve a Unix filozófia nem értelmezhető kernelszinten. Az a shellben használt CLI megoldásokra lett kitalálva, ott jól is működik, nagy támogatója is vagyok, de kernelnél, GUI-s programoknál, stb. nem játszik, nem értelmezhető.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ezt én a videó elindítása után az első percben sejtettem (a hangjáról). Nekem ezzel semmi bajom.

Azzal viszont van, hogy a régi e-mail címéről más néven írogat. Ezt elegánsan meg letett volna oldani egy forward használatával. Akkor az ember nem kapkodná a fejét.

trey @ gépház

Tudom. Nekem a RIPE-nal volt egy kollega, aki szinten nevet valtott ily modon. Egyszeruen nem szoktunk hozza, itt MO-n ugye plane nem. Normalis, hogy az ember felvonja a szemoldoket, zavarban van, nem mer hozza szolni se, nem tudja, hogyan kezelje a szituaciot. Es ilyenkor konnyu elmenni frusztracioba, es utalni az egeszet. Ez az agy alapveto vedelmi reakcioja kognitiv disszonancia eseten.

En szemelyesen dolgoztam vele, amikor meg fiu volt, es egy total baratsagos, kedves, ugyes koderrol van szo. Biztos, hogy nem poenbol vagy divatbol csinalta, hanem tenyleg igy erzi jobban magat. Ez van. Van, akinek hosszu a haja, van, aki bajusz-koltemenyt visel, van, aki borotvalja a labat, van, aki tetovalja magat, van, aki fulcimpa-tagitokat hord, van, aki fiusan/lanyosan oltozkodik, es igen van, aki ezeknek a kombinaciojat. Nem ettol lesz valaki jo vagy rossz ember.

Amugy egy apro adalek: a legtobb LGBT... amugy teljesen normalis ember, es ranezesre meg nem mondanad rola, hogy az, ami. A divatfiukakat, paradezokat konkretan nem szeretik, tulsagosan nyalas, muvi, fennhejazo nekik. Gondolj bele, te is ruhelled a primadonnakat, divakat, ahogy viselkednek, hat az kb. ugyanaz LGBT korokben. Legalabbis az irodaban, a gyakorlatban ez a hozzaallas.

Azért ezt az IT mai szintjén már meg kellene tudni oldani. Az android contacts-ban be lehet írni becenévnek a leánynevet, és akkor leánynéven és asszonynéven is megtalálod az illetőt. Szerintem ennyit el lehetne várni egy könyvelő- vagy iktatórendszertől is.

Más okból is szerepelhet egy csomó helyen két név (pl. ismerek több olyan embert is, akinek két keresztneve van, a szülei az egyiken szólították, de ő a másikat szereti jobban, meg olyanokat is, akik nevet változtattak, amikor megkapták az állampolgárságot ott, ahol laknak (a kínai írásjeleket úgysem tudtuk elolvasni addig sem), illetve MO-on pl. a tudományos fokozat is a neved része lesz).

Nem, de megkereshetem email cím alapján. Nem az archívumon kell bármit is változtatni, legfeljebb a keresőn, hogy megtalálja a régebbi hozzászólásait is. Az lenne rosszabb, ha az emailt is megváltoztatta volna, mert a programozási stílusa és tudása valószínűleg nem változott.

Ezzel kezdtem. Olvasd el feljebb.

A szemem pedig azért zavarja, mert üzemeltettem elég e-mail rendszert.

általa írt programon

Úgy érted, hogy írtam-e neki, hogy írjon egy ilyen programot? Megfizeti a munkaadója ezért, ha jól láttam, céges e-mail címről kommunikál. Az a szoftver, amit munkaidőben fejlesz jogilag a cégéé, a copyright az övé max.

Hova kívánod terelni a beszélgetést?

trey @ gépház

Most komolyan, az zavar, hogy kellett egy picikét gondolkoznod, amikor rákerestél, hogy ki is ez? Vagy az, hogy ha egy parallel univerzumban te csinálod a Codeweavers könyvelőrendszerét, akkor le kell fejlesztened ezt a rendkívül bonyolult fícsört?

Hova kívánod terelni a beszélgetést?

Oda, hogy csak eteted az egésszel a politikai flamewart, hogy aztán hátradőlve popcornt zabálj, miközben magas lesz az oldal látogatottsága.

Nem nálatok dolgozik, nem a te gondod. Az már legyen a Codeweavers problémája, hogy ott hogy szerepel, az USA-é, hogy mi van a driver's licence-ében, az meg, hogy hogy küld levelet egy nyilvános levlistára, az övé. Egyáltalán átment a levél a Codeweavers SMTP-szerverén?

Mindenesetre magyar cégnél nem okozott gondot az a névváltozás semmilyen tanúsított policy-ben, hogy be kellett iratnom a nevemhez a tudományos fokozatot. A kimenő levelekhez mondjuk nem írjuk oda, mert a cég jó 2/3-ának van.

Semmiféle problémát nem okoz, ugyanis ilyenkor (névváltoztatáskor) hozzáadnak egy alias-t a fiókhoz az új névhez tartozó címmel, a Primary Address-t átbökik az új e-mail címre és megy tovább az élet. Természetesen a kimenő levelek onnantól az új e-mail címmel mennek ki.

 Na, ez az utolsó hiányzik innen.

trey @ gépház

( KGer | 2024. 01. 28., v – 23:17 )

Szerkesztve: 2024. 01. 28., v – 23:21

az ötlött be ha tényleg létezik ekkora performance hole, akkor miért most 2024-ben jön erről cikk? Ezt 10 éve is ki kellett volna mérniük, valszeg ki is mérték.
 

Lehet akkor is kimérte valaki, lehet nem, csak elfogadták, hogy a Linux nem Windows, vagy betudták emulációs overhead-nek, hardvergyengeségnek. Akkoriban még kevesebben dolgoztak ezeken a kódokon. Legalábbis messze nem annyian, mint ma.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

egyreszt akkor meg talan nem volt sokmagos cpu minden desktop gepben, legalabbis ha jol ertem es a nagy szamu cpu core eseten hoz jelentos javulast.

masreszt 10 eve meg nem volt a wine mogott ekkora szponzoracio (es nyomas), mint most a gaming miatt.

anno leginkabb a codeweavers szponzoralta a wine fejlesztest, de ok inkabb az irodai appokra gyurtak, ott meg nem kell multicore.

Megnéztem az előadást. Mondta a srác, hogy nagyon régi a probléma, tudnak róla régóta, de eddig megpróbálták user-space-ben megoldani ameddig csak lehetett. A "miért most"-ra a válasz az, hogy mivel már nem tudnak tovább gyorsítani, ezért kernel driver kell, azt meg ki kell fejleszteni, és hozzáilleszteni a userspace libeket. Ez mostanra érett be.

Kíváncsi vagyok, hogy Linus-ék befogadják-e az upstream kernelbe. Nem csak a játékok fognak profitálni belőle. Steam Deck felkészül :)