Fórumok
Hali,
A tárgyban szereplő kérdésre keresem a választ.
Az érdekelne, hogy 64 bit-es host rendszeren melyiket lehet gyorsabb virtualizálni, 32-, vagy 64 bit-es guest rendszert? Tegyük fel hogy van hardver-es támogatás.
Van valakinek ezzel tapasztalata? Talán benchmark-ot is lehetne futtatni?..
Hozzászólások
Én csak tippelek, de szerintem felesleges benchmark-ot csinálni. Megközelítőleg ugyanott lesz a két eredmény ha azt vesszük figyelembe, hogy általában a merevlemez I/O a mérvadó.
De azért engem is érdekel a dolog. Valaki?
#define gyorsabb.
Miben gyorsabb? Mihez kepest gyorsabb? Milyen alkalmazasrol, OS-rol beszelunk?
Egy 386-oshoz kepest pl. gyorsabb akarmelyik. Egyebkent meg 42.
--
engem általánosságban érdekel a kérdés. ha nincs általános válasz, akkor nézzük úgy, hogy pl. 64 bites linux host rendszeren 32 bites vagy 64 bites linux guest rendszer fut gyorsabban ahhoz képest, mintha fizikailag lenne a vasra telepítve a 32 vagy 64 bites rendszer.
persze sok mindentől függhet, pl. kernel verzió stb. én azt szeretném kideríteni, hogy lehet-e általánosítani a kérdésben csak a 32 bit és 64 bites tulajdonságot figyelembe véve? tehát mindegy mit hasonlítunk össze, csak a 32 és 64 bit közötti sebesség különbség érdekelne önmagukhoz képest, mintha fizikai vason futnának.
A fizikai vashoz kepest a virtualis mindenkeppen lassabb lesz, mert van plusz 1 reteg a vas meg az OS kozott, a hypervisor. A kerdes az, hogy az alkalmazas szamara erezheto-e a lassulas.
A 32 es 64 bites gep kozotti kulonbseg pedig nem hinnem, hogy nagyon elterne a fizikai vasra telepitett 32 es 64 bites rendszerek kozti differenciatol, mert a virtualizacio ilyen teren nem okoz hatalmas kulonbsegeket. Persze, itt megint elojon az, hogy nem definialt dolgokrol beszelunk, tehat nagyon levegoben logo dolgokat lehet csak mondani, mindenfele konkretumok nelkul.
Amire nagyon oda kell figyelni virtualizacional, az elsosorban a Disk IO, mivel tobb gep hasznal egy storage-t (hogy ez halozatos avagy sem, ez jelen temaban irrelevans). De ez megint nem fugg a bitek szamatol (32 vs 64). Ezert mondtam, hogy definiald, mit szeretnel virtualizalni, mert az alapjan lehet peldaul meroszamokat keresni, lehet tudni, hogy milyen teren intenziv az alkalmazas. Nyilvan a CPU terheles meroszamai el fognak terni a fizikai vason tapasztaltaktol, mert oda igen erosen beleszol a virtualizacio, de hogy pontosan mennyire, es hogy ez lassit-e erezhetoen, az megintcsak alkalmazasfuggo, nem letezik egzakt valasz. Egy /bin/true peldaul ugyanolyan kurvagyors virtualis gepen, mint fizikain, nincs szamottevo lassulas :-D . Ugyanakkor egy erosen CPU intenziv nagyonbonyolult matematikai feladatot megoldo cucc esetleg komoly pofonokat szenvedhet el teljesitmenyileg.
--
Egy /bin/true peldaul ugyanolyan kurvagyors virtualis gepen, mint fizikain, nincs szamottevo lassulas :-D . Ugyanakkor egy erosen CPU intenziv nagyonbonyolult matematikai feladatot megoldo cucc esetleg komoly pofonokat szenvedhet el teljesitmenyileg.
Pont fordítva. A /bin/true-nál az alkalmazás gyakorlatilag csak rendszerhívásból áll (process indítás, program kód, library betöltés, memória foglalás, majd rögtön utána process leállás, felszabadítás, összesen 24db). A rendszerhívás pedig a virtualizációnál drága dolog, mert mindig egy kört jelent a hypervisorban is.
Egy sokat számoló alkalmazás viszont alig fog lassulni, mert az idő nagy részében nem-privilegizált utasításokkal és rendszerhívások nélkül számolgat magában, a hypervisor beavatkozása nélkül tud nyugiban futni.
---
Internet Memetikai Tanszék
Ez attol fugg. Ha olyan utasitasokat hasznal a szamolo alkalmazas, amit az emulator (nem feltetlen hypervisor!) csak emulal, akkor bizony csokkenhet a teljesitmenye.
Persze, itt megint az van, hogy kellene egy kontextus, amiben beszelgetunk. Ha mondjuk VirtualBox, az nem igazan hypervisor, ott az emulacionak nagyobb mindenutt az overheadje, mint a nyers vas eseteben. Xen/ESX eseteben valoban all az, amit irtal, de az ilyen magasabb szintu emulatoroknal mar sok procihivas atszalad az emulatoron is, akar csak annak ellenorzesere, hogy kell-e neki ezzel foglalkoznia, ez viszont akkor is koltsegesebbe tesz minden muveletet, mintha a nyers vas dolgozna. Ezen segit valamennyit a procikba epitett virtualizacios tamogatas, de a gond arrafele is keresendo, hogy ezek az emulatorok ugy vannak megirva, hogy tamogassak a cpu-support nelkuli mukodest is - emiatt is veszhet valami minimalis teljesitmeny a hypervisorokhoz kepest. Sok pici meg sokra tud menni.
--
Na egy pillanat, akkor pár fogalmat tisztázzunk, mert szerintem nem ugyanarról beszélünk.
A hypervisor-t tényleg szerencsétlen volt emlegetnem, mert legalább 3-4 különböző jelentése van. Nevezzünk inkább VMM-nek (virtual machine monitor), ez architektúrától függetlenül mindenben kell hogy legyen, Xen, Vbox, ESX stb. Ennek a feladata a CPU által elfogott _privilegizált_ utasításokkal kezdeni valamit, leginkább emulálni a hatásukat. A többi, CPU üzemmódot nem váltó utasítás (a sima számolások, függvényhívás sima call-lal, elágazás, mind ilyen) simán fut a CPU-n, mintha ott sem lenne a VMM alatta. Ettől virtualizáció a virtualizáció, az utasítások túlnyomó többségét nem kell emulálni.
A legtöbb CPU utasításkészlet hülyén volt kitalálva és vannak CPU olyan globális CPU állapotot/üzemmódot módosító utasítások, amiket nem lehet elfogni. Pl x86-on a nem ring0 CPU védelmi szinten kiadva a POPF egyszerűen nem csinál semmit, ahelyett, hogy a Ring0-s kódban az illegal instruction trap handlerhez kerülne a vezérlés. Erre két megoldás van:
- szoftveres virtualizáció (binary translation etc.) esetén valami fordító átnézi a futtatható kódot tartalmazó memórialapokat, hogy kicserélje az el nem fogható utasításokat valami rendszerhívásra, hogy a VMM-hez kerülhessen a vezérlés és az emulálni tudja a hiányzó utasítás hatását.
- hardveres virtualizációnál a CPU utasításkészlet meg van patkolva, hogy mégis elfoghatóak legyenek a privilegizált utasítások.
- paravirtualizációnál meg módosítjuk a guest-et úgy, hogy ne akarjon nem elfogható utasítást végrehajtani
Nyilván a binary translation esetén a futtatható kódot egyszer az első futás előtt át kell vizsgálni (szerintem te erre gondoltál), DE egy számításigényes alkalmazásnál általában egy viszonylag rövid ciklusmag fut nagy méretű adathalmazon. És ez a ciklusmag tipikusan nem hajt végre rendszerhívást, sem pedig privilegizált utasítást. Csak az lehet kivétel, ha sok memória allokálást/felszabadítást csinál menet közben. De ez mondjuk önmagában is agyon tudja csapni a teljesítményt, fragmentálja a memóriát, szóval ezt szeretik elkerülni vagy valamilyen saját memória menedzsment/garbage collection megoldást berakni.
A lényeg, hogy egyszer kell csak elszenvedni a bináris fordítást, utána zavartalanul futhat, legfeljebb az ütemező időnként preemptíven megszakítja. Persze, ha az algoritmus önmódosító kódot használ, akkor lehet nagy overhead, de általában a run-time kódgenerátort használó number-cruching alkalmazások (pl. fftw) is úgy működnek, hogy a feladat elején a paraméterek alapján optimalizálva lefut egy kódgenerálási fázis és utána a generált kód fut sokáig változatlanul.
---
Internet Memetikai Tanszék
ez hasznos, köszi.