Meltdown / Spectre javítás hatása (Java)

Hát ez eléggé visszadobott :-(

vmWare, ubuntu 16.04
Tomcat start: viszonylag nagy mennyiségű serializált adat betöltésével (~800 MByte)
kernel frissítés előtt: 54 sec
kernel frissítés után: ~300 sec
kernel frissítés után (patch kikapcs: pti=off): 78 sec

KVM, ubuntu 16.04
Tomcat start: viszonylag nagy mennyiségű serializált adat betöltésével (~800 MByte)
kernel frissítés előtt: ~80 sec
kernel frissítés után: ~140 sec

LXC, ubuntu 16.04, (Itt a host is biztosan patchelve van)
Tomcat start: viszonylag nagy mennyiségű serializált adat betöltésével (~800 MByte)
kernel frissítés előtt: ~80 sec
kernel frissítés után: ~150 sec

Hozzászólások

Annyira azért nem kell sírni, tekinthetjük ezt egyfajta időutazásnak, visszarepültünk 5 évet sebességben...
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Én meg i7-2620M-en észre sem veszem, hogy lassabb lenne a foltokkal, teljesen átleg felhasználás mellett. Igaz én nem fejlesztek, nem szervert üzemeltetek, meg nem adatbázisozok. Azért ne túlozzunk, a C2D szinthez nagyon sokat kéne visszaesni.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Nem mondom, hogy nincs benne költői túlzás, de én nem érzem a C2D gépem lassúbbnak, amíg a neten böngészek vagy épp valami IDE-t futtatva turkálok python kódban. Talán a fullHD videók lejátszásánál lenne látható, de notebookon az i5 integrált procija van, a C2D mellett meg valami akkor bikának számító nvidia, ami úgy vettem észre, ebben sokat segít.

Kernel verzio?
Mi drasztikusan pocsek eredmenyeket latunk HWE kernellel. A standard kernel viszonylag jol teljesit.
Bar en elsosorban meltdown utani allapotot vizsgalom, hogy ott mi a legjobb.

Január elején írtam egy szintetikus tesztet C-ben, amely kernelhívásokkal terhelte a rendszert.
Ebben a szélsőséges tesztben volt proci, ahol tizedére esett a teljesítmény a régi és Meltdown javítást tartalmazó kernel között.

Ekkor megörültem, hogy annó a C-ben írt teljesítményorientált programoknál jól döntöttem:
- I/O buffering az alkalmazáson belül, ezáltal ritkább read/write kernelhívás.
- ahol lehetett mmap() a read/write helyett.
- ...

Így ezeknél a programoknál megúsztam néhány százalékos teljesítménycsökkenéssel.
Az egészben tényleg azt kell látni, hogy maga a kernelhívás lassult le. Amíg az alkalmazáson belül tud futni a kódod, addig a proci maradt ugyanolyan gyors.

Próbáljátok ki 4.15.2-es kernellel. Abban van mindhárom sebezhetőségre tisztán szoftveres javítás (Spectre1 ellen user pointer sanitization, Spectre2 ellen full generic retpoline, Meltdown ellen PTI), ami sokkal kisebb mértékben lassít, mint a mikrokód alapú javítás. Plusz a retpoline-on és a PTI-n csiszoltak teljesítményügyileg is, meg egy csomó új optimalizáció bejött (a Phoronix írt róla, este teszek be linket), ami ellensúlyozza ezeknek a foltoknak a hatását, a 4.16-os ágból vannak ezek visszaportolva 4.15.2-re.

Plusz szerveren nyugodtan ki lehet ezeket a javításokat kapcsolni a nopti, noretpoline, meg gondolom az sanitization is letiltható kernelparaméterrel. Szerveren (meg mondjuk fejlesztésre használt virtuális gépen) ugyanis nem böngésztek, meg csak ellenőrzött kód kerül fel, így nincs ami kihasználja a sérülékenységet, ezek a spekulatív végrehajtást érintő rések nem használhatók ki távolról, csak a helyi gépre felkerülve és futtatva. Desktop felhasználónál fontos, aki minden szutykot futtat a gépén meg a fene tudja milyen oldalakat látogat és ott milyen szkriptek futnak le.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum