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

 ( yoursoft | 2018. február 10., szombat - 12:07 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Na ja, de közbe a szoftver lassabb lett, mondván, hogy "vegyé jobb hardvert, hülye gyerek!". :D

Sok helyen hanyagolják az optimizációt ilyen nézetek miatt. :/

Szerintem az Intel még örül is ennek a hibának. Hiszen kívánt teljesítmény eléréséhez mostantól jóval több processzort adhat el.
Vagyis az egészből jól csak az járt akinek a hibát köszönhetjük.

Tizenötöt. Öt éve az akkori i5-2520m semmivel sem volt lassúbb, mint most az i5-6300u, patch nélkül.
Felhasználói élmény tekintetében most közelebb járok a core2duohoz. :(

É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.

Ez van:
4.4.0-112-generic

Mentem vissza 109 ala, mert esett kelt a gep 112 alatt.
Nem intel, oreg vas nem baratolja ezt a javitast ahogy latom.
CPU Lx cache akarmiket emleget a panicban.

http://karikasostor.hu - Az autentikus zajforrás.

elkérhetném a panic teljes szövegét? virtuális gépről van szó?

szerk. 'öreg vas', szóval a második kérdésem érvénytelen.

----------------------------------
szélsőségesen idealista, fősodratú hozzászólás

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.

Rendszer hivasok szamanak minimilizalasa, mindig jo otlet.
En a `javitas elott` is draganak talaltam.

mmap sajnos nem fog megmenti ebben az esetben,
ha lap hianyzik a kitoltesehez/bevesesehez szinten contex switch kell.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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