[Folyamatosan frissítve #4] Meltdown és Spectre - kihatások a teljesítményre patchelés után

Bug

syslog-ng fordítás

Epic Games

DragonFly BSD

BigData, Tensorflow ...

( sz332 v | 2018. 01. 08., h – 11:36 )

Tippre a build szerverek és a fejlesztői gépek nem igazán lesznek felpatchelve...

( dejo v | 2018. 01. 08., h – 11:49 )

A processzorok visszahívása ilyen esetekben szóba sem jöhet?
Elvégre szoftveres javítás után is csak teljesítmény csökkenés árán működik.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Én egy szóval nem mondtam, hogy mindegy, mert szerintem egyáltalán nem mindegy. Én csak azt mondtam el, hogy szerintem dejo mire gondolhatott, hogy az átlagjóska nem veszi észre a dolgot.
Az igaz, hogy egy összeszart windows az alapból is lassú, de win-t rengetegen használnak az ipari, kereskedelmi, kreatív szektorokban is, ahol viszont baromira nem lesz mindegy és ők észre is fogják venni.

Nem mondtam, hogy mondtad :) úgy gondolom, hogy sokan észreveszik, sokan nem. Otthoni Windows 10-es Celeron 1007U-s asztali miniPC-n semmi változást nem tapasztalok peccselés után. Ez a gép átlagfelhasználás céljából van, arra elég is, még így is. Példám biztosan nem egyedi, de lehet nem is tipikus.

Most a média felfújja ezt az egészet, pár hónap múlva meg röhögni fogunk az egészen, egy Failure lesz a sok közül - amúgy már most is az, elég szépen gyarapodik a CVE könyvtár.

--
robyboy

És mire cserélnék ki?

Vagy arra gondolsz, hogy visszaküldjük a processzort, és helyette kapunk egy 30%-kal gyorsabbat, ami a patch után kb. akkora sebességű lesz, mint az eredeti a patch nélkül? Aztán ha az alaplap nem támogatja az új procit, akkor az így jártunk esete lesz?

AMD marketingesei most javában (no pun intended) zakatolnak, hogy akkor most hogy is írjuk rá a dobozra, hogy meltdown,spectre mentes processzor, és hogy hogy rajzoljunk intel -spectre -meltdown vs amd factory state grafikont, ami mutatja, hogy az amd már nem is lassabb esetleg, ha vesszük ezt a javítást. Kicsit hasonló a kérdés, mint amikor kiderül, hogy hát olcsóbb, de többet fogyaszt, akkor megérte-e.

Most valami újat kell kitalálni. Javítani akkor kellene, ha implementálási hiba lenne. Azonban itt protokoll hibáról van szó. Tehát előbb ki kell találni egy olyan protokollt/algoritmust, ami legalább elvi szinten nem hibás. Után lehet nekiállni a konkrét megvalósításnak.

Az egy dolog, hogy újra kell tervezni az architektúrát. Egy másik meg, hogy hány hibás lapka van legyártva, készleten, piacon, amiket ugyanúgy el fognak adni, mint eddig. Mert kb. mindenki leszarja (értsd: nem akar rajta bukni) és eladja a meglévö készleteket ugyanúgy, mint eddig.
Ez nevezhetjük az igazi átb@szásnak, mert már mindenki tud a dologról, ergo szándékosságról is beszélhetünk.

A CPU visszahívásnak ezekben az esetekben minden esetre müködnie kellene.

További aggályom az esettel kapcsolatban, hogy elhitetik a felhasználókkal, hogy ez a hiba orvosolható, csak telepíteni kell ezt+azt a peccset. Ez teljesen téves elképzelés, de nyilván az indulatok csitítására böven alkalmas.
Sajnos ez a hiba szoftveresen nem javítható, a Workaround-ot nem nevezném javításnak.

--
robyboy

Akkor az eladott CPU-k után részleges visszatérítés és az ezután ugyanezzel a hibával eladandó CPU-k esetében érzékelhető árcsökkentés!
De szerintem fordítva fogják megoldani és a hibával nem érintett következő generáció árát fogják jól feltolni.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Pedig itt pont, hogy teljesen egzakt mérési módszerekkel kimutatható egy előtte-utána állapot, nem kell a levegébe beszélni egyrészről, másrészről meg már az egész világ tudja, hogy hibás a termék, és azt az Intel is "elismerte". Van egy funkció, amiért fizettél, ami nem működik, és ami garantálta volna a termék eredeti teljesítményét.

Ez nem ugyanaz, mint amikor veszel egy autót, ami amúgy menne 300-al is, de leszabályoz 250-nél biztonsági okokból.
Itt nem tudtad, hogy amit veszel, az milyen "rejtett "tartalékokkal"" rendelkezik. Ja, és még nincs vége. Ki tudja, még mik lesznek itt? Csak ki kell várni.
--
robyboy

Így van. Nem lehet mire hivatkozva cserét kérni. A procik működnek mai is, megvannak a magok, frekvencia, futtatják a szoftvereket. Az Intel anno eladáskor sehol nem ígérte, hogy hibátlan lesz a proci, és biztonság terén is 100%-ban lesz flott, emiatt most az asztalt sem lehet verni.

A procik visszahívása sem jön szóba, ha még lenne is olyan új proci gyártósoron, amely már nem tartalmazza a hibát, akkor sem tudnának hirtelen annyi procit gyártani, amennyi kéne a cseréhez, meg akkor minden korábbi generációból, foglalatból is kéne gyártsanak.

„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

Pár évtized múlva processzorok lesznek az emberekben is, ld. cyborg-ok, különbözö célokból. Aztán majd sokan meghallnak egy számítási hiba, vagy biztonsági rés miatt. Perelni majd akkor sem lehet, mert aláíratnak mütét elött egy papírt, hogy vállalod a rizikót.

"kicsit" elöre szaladtam az idöben.

--
robyboy

Persze latom a smajlit, de az egy-ket honap kevesnek tunik.

A chip legyartasa fizikailak (az eljaras lassusaga miatt) honapo(ka)t vesz igenybe ez csak az az ido, amig a teljesen vegleges(nek gondolt) designt a gyarto megkapja es kigordul az elso chip. Ami szinte biztos, hogy nem lesz jo, tehat tovabbi iteraciokra lesz szukseg, ahol szaguldanak a hetek (meg ha csak maszkot kell valtoztatni akkor is eleg sok ido, de ha base layer akkor meg durvabb).

Ezelott meg meg is kell tervezni a chipet, ami nem nullarol indulva is ev+ altalaban, de nem ritka, hogy tobb ev, mire gyartasba tud kerulni (az emiltett prociknal joval egyszerubb dolgok eseten is).

Es ez csak a muszaki resze, valoszinuleg a donteshozok es marketingesek is vitatkoznak egy par honapot, meg felmerik a terepet mielott zold utat adnanak a projectnek.

Szoval ha az egesz most elkezdodne, akkor is evet vagy eveket kellene varni, mire a vasarlo a kezebe vehetne a termeket.

Szerintem az Intelnek azok a prociai amiket most dobnak piacra, lehet, hogy mar vagy ot eve odakerultek a managerek asztalara tervkent (otletkent).

/sza2

Viszahivni az oszes erintett CPU-t szerintem relativ "abszurd" elvaras.
Mivel az Intel es partnerei mar Junius/Julius-tol tudnak rola, de ennek ellenere tovabbra is ertekesitettek a most mar nyilvanvaloan sebezheto termekeket - kihasznalva az embrago nyujtotta vedelmet - azok cserejet (amint lesz javitott hardware) szeritem jogosan kerhetik a vasarlok.
Valoszinunek tartom, hogy meg is indulnak a perek ha az Intel es tarsai nem lepnek hamarosan.

( Kobor | 2018. 01. 08., h – 12:33 )

Epic-et nem ertem, ha nagyobb a CPU hasznalat, akkor inditsannak tobbet. Miert fogjak erre a problemaikat?
Azert felho. Majd verjek le a felho szolgaltaton hogy a node-ok nem az adott teljesitmenyt hozzak. Majd a szolgaltato verje le az Intelen, problem solved.
Vagy menjennek dedikaltra es ne upgradeljennek. Gondolom naluk (legtobb ) szerveren egy service fut, igy igazan nem gond hogy mas futo process eler nem neki szant memoria teruletet.

( turul16 v | 2018. 01. 08., h – 12:46 )

getppid(2) 4x lassabb, effective minden ami systemcall intensive, halozat/disk hozza feres lassabb lesz,
nem valszinu, hogy memory mapped I/O jobb lenne. Ill. megszakatas kezelesre is hasonlo hatas varhato.

Egy contex switch koltsege 386-os idokre emlekzetotoen magas lett.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( wowbagger v | 2018. 01. 08., h – 14:08 )

remekül hangzik
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

( czanik | 2018. 01. 08., h – 14:16 )

És hogy legyen jó hírem is: gép BIOS frissítés után a fordítás idő nálam normalizálódott. De ezzel együtt a frissítés bármennyire szükséges, akkor is orosz rulett. Az eddigi visszajelzések alapján legtöbb embert nem nagyon érinti, ugyanakkor ránézésre teljesen random szoftver - hardver kombinációknál durva lassulások vannak.

( apostroph3 | 2018. 01. 08., h – 19:20 )

akkor nagyon gyorsan neki kell állnia mindenkinek, hogy jobb, gyorsabb kódokat állítanak elő, és végre 50 év után gondot fordítsanak az optimalizálásra is.

( freeoli v | 2018. 01. 08., h – 20:10 )

2018 a szervergyartok nagy eve lesz. Ezzel a hibaval most berugtak a penzszivattyut de nagyon. Mar szamolom hany vasat kell vennunk a vmware clusterbe.

( s7stM | 2018. 01. 08., h – 22:50 )

(sub)
-------
It is our choices that define us.

( micsa v | 2018. 01. 08., h – 23:13 )

én ezeket mértem:
- ez a hardver: laptop, i7-3632QM CPU, 16G RAM, Samsung 840 EVO
- ez a szoftver: Manjaro, gcc 7.2.1, amit buildeltem: syslog-ng-3.13.2
kernel 4.9.68-1-MANJARO #1 SMP PREEMPT
kernel 4.9.74-2-MANJARO #1 SMP PREEMPT (igen, benne van a /proc/config.gz-ben a CONFIG_PAGE_TABLE_ISOLATION=y)
- ahogy buildeltem: sima makepkg (a PKGBUILD file-ban sime make van, próbáltam make -j4 -gyel is)

- az eredmények:
4.9.68:

real 3m52.591s
user 3m32.840s
sys 0m18.067s

real 3m51.345s
user 3m32.587s
sys 0m17.597s

make -j4-gyel:

real 2m6.929s
user 3m34.367s
sys 0m16.463s

4.9.74-2:

real 3m56.452s
user 3m32.223s
sys 0m21.997s

real 4m11.778s
user 3m43.383s
sys 0m23.403s

make -j4 -gyel

real 2m11.700s
user 3m36.460s
sys 0m19.947s

szóval nem számottevő a különbség

Én a munkám során használatos numerikus módszereimet teszteltem, de nem csak kicsi, hanem semmi különbség nincs a számítási teljesítményben.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

( uid_16313 | 2018. 01. 09., k – 07:33 )

Belegondoltam, az lenne igazán a "dupla zakó", ha kiderülne, hogy peccselés után gyorsabbak lettek a rendszerek :)

--
robyboy

Átalában igaz. De néha nem. Például fordítsd le gcc -O2 -vel assembly-re a 

int modulo10(int num) {
   return num%10;
}

Bár ezt assembly oktatáson div-vel oktatták, amely visszaadja a maradékot is, ennek ellenére a GCC szoftveres trükkel tud dupla gyors megoldást (szorzás, shift, összeadás, kivonás).

Nekem a régebbi "RAID"-vezérlök jutottak az eszembe, amik lassabbak voltak, mint maga a CPU, ezért aztán nagyobb teljesítményt lehetett elérni a tisztán szoftveres RAID-ekkel.

Persze ez itt most már helyzet, de vicces lett volna átélni egy ilyet, azt hogyan magyarázta volna ki Àrpi :)

--
robyboy

( hajbazer v | 2018. 01. 09., k – 20:37 )

A múlt héten arról írt a The Guardian, hogy az első három csoportos keresetet beadták az Intel ellen. Egyes hírek szerint azonban az Intel további csoportos keresetekre számíthat. Megjegyzem, nagyon helyesen és jól megérdemelten.

A lakájmédia és az informatikai biztonsággal foglalkozó orgánumok természetesen mélyen kussolnak, elkerülendő, hogy még nagyobb csorba essék hardvermultiék hírnevén. A szélsőségesen vadkapitalista ZDNet ráadásul odáig merészkedik, hogy a botrányra való tekintet nélkül lehoz egy Intelt fényező cikket, avagy elülteti a bogarat birkáék fülében, mire kell majd gyűjteni a zsetont, ha már a gyári hibás, agyonpeccselt processzorok nem elég gyorsak.

A fizetett bértollnokok tehát szorgalmasan teszik a dolgukat. Nehogy eszébe jusson sokaknak számon kérni az Intelen egy gyári hibás termék gyári hibáit. Nehogy ráeszmélhessen valaki, hogy a jelenleg a felelősség alól kibúvókat kereső, és a magát rögtönzött PR-köpönyegforgatással mosdató Intel profitéhsége, versenyelőny mindenek fölé helyezése, mérhetetlen felelőtlensége és nemtörődömsége vezetett ide. Nehogy eszébe jusson sokaknak számon kérni az Intelen, hogy annak ellenére dobták piacra az új, Coffee Lake processzorfamíliát, hogy már rég tudtak a galibáról. Nehogy eljusson valakinek a józan eszéig, hogy utóbbi nem volt más, mint a fogyasztók szándékos megtévesztése. Nehogy ne törődjön bele mindenki a teljesítménycsökkenésbe és ne engedelmes cloud-birka módjára bővítse gépparkját, a kieső teljesítményt pótolva.

A lakájmédia elért sikereibe pedig már itt a HUP-on is úton-útfélen belebotolhatunk. Többen új gépek vásárlásáról és az Intel számonkérésének hiábavalóságáról vagy lehetetlenségéről beszélnek. Sőt, valaki odáig merészkedik, hogy a számonkérés hivatkozási alapját is megkérdőjelezi. Így már értem, hogyan süllyedhettünk idáig, ha a fogyasztók képesek ennyire saját maguk és egymás ellenségei lenni.

Ez ugyanaz az eset, amikor egy orvos orvosi mühibát követ el, és emiatt meghal a páciens. Aztán utána fel sem mond, meg el sem ítélik, mert kimosdatják inkább a felelösségrevonás helyett.

Sajnos a világot nem tudjuk megváltoztatni, van böven elég pénze, piaci hatalma, befolyása az Intelnek, hogy kb. minden úgy történjen, ahogy ö szeretné.

Most tényleg: mit vegyen az ember, ha nem Intelt? Van IGAZI alternatíva? Az elmúlt évtizedekben szépen leölték a konkurrenciájukat.
AMD talán jó úton halad, de a Spectre pl. öket is érinti, egyik kutya, másik eb.

Talán nem másolni (lopkodni) kellene a technológiát, hanem jól kitalálni, és jól fejleszteni.

--
robyboy

( _Franko_ v | 2018. 01. 09., k – 23:16 )

[ 0.000000] Kernel/User page tables isolation: enabled

Ööö... izé... mértem Java projekt fordítást, normál esetben 2-4 perc egy komplett fordítás (Wildfly integrációs tesztekkel, i7-6700HQ) és pár másodpercen belül volt a különbség új kernellel is... vajon mit mértem rosszul? :)

Nem mit, min. Az Intelfényező üzemmódba való átkapcs előtt azért vedd figyelembe azt is, hogy nem mindenkinek futja i7-6700HQ-ra és egy nem bika gépen nagyságrendekkel nagyobbak a különbségek. Nagyon örülünk, hogy ilyen Frankó géppel ilyen Frankón megúsztad a javítással járó performance csökkenést. Ez viszont mindenkinek sovány vígasz, aki gyengébb hardvert használ (pl. 2. és 3. generáció). Amiken egyébként inkább van értelme mérni, mivel hardvermultiék azokat akarják elsősorban kidobatni, nem a félmilliós laptopod 6. generációs processzorát.

"Az Intelfényező üzemmódba való átkapcs előtt azért vedd figyelembe azt is, hogy nem mindenkinek futja i7-6700HQ-ra és egy nem bika gépen nagyságrendekkel nagyobbak a különbségek."

Ez egy mérés, minden mást te értesz bele. Várom a mérésed a nem bika gép kapcsán.

"a félmilliós laptopod 6. generációs processzorát"

Aham... 230 ezer forint volt. Bruttó.

Várom a mérésed a nem bika gép kapcsán.

Nem mérés ugyan, de rokonságban egy low-end, "lemerült ceruzaelemről 8 órát elfut mert kenyérpirító számítási kapacitásával bír" Atomon r=1 user desktop felhasználással nincs észrevehető különbség.

Úgyhogy a szemét vadkapitalista extraprofitos Intel biztos a középmezőnyt célozta, hogy átverje a usereket.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Èn is ezt tapasztaltam egy Asus VM40B-n, Windows 10 alatt, viszont:

1. A BIOS nincs és lehet nem is lesz frissítve
2. A Windows 10 patch csak a Meltdown-t foltozta be tudtommal
3. A Spectre foltozása fog nagyobb teljesítményveszteséggel járni

Tanulság: várjuk ki a végét

--
robyboy

( SzBlackY | 2018. 01. 10., sze – 08:09 )

Subscribe.

A saját gépeinken egy hét múlva az elmúlt havi CPU grafikonokat, hogy van-e különbség (leginkább standard desktop usage), eddig szerencsére nem jöttek lincselni, hogy fúdelassúminden.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( uid_16313 | 2018. 01. 10., sze – 10:09 )

Ehhez mit szóltok?

NetApp nyilatkozat:

"ONTAP: Unlike a general-purpose operating system, ONTAP does not provide mechanisms for non-administrative users to run third-party code. Due to this behavior, ONTAP is not affected by either the Spectre or Meltdown attacks. The same is true of all ONTAP variants including both ONTAP running on FAS/AFF hardware as well as virtualized ONTAP products such as ONTAP Select and ONTAP Cloud.
While ONTAP Select and ONTAP Cloud are not directly affected by these attacks, these attacks may be possible against the utilized hypervisor platform. NetApp recommends working with your hypervisor and cloud platform vendors to ensure that your NetApp product is running on a secure and patched platform."

--
robyboy