Helyretette Linus a Linux ütemező teszteket készítő bloggert

Kernel

Malte Skarupke játékfejlesztő blogjában arról írt, hogy a Google Stadia játékfejlesztőknek milyen problémákat okoznak a Linux kernel (processz) ütemezőjének problémái. Állításait igyekezett méréseredményekkel is alátámasztani. Linus egy hosszabb posztban tette helyre a szerinte teljesen tévúton járó bloggert:

The whole post seems to be just wrong, and is measuring something completely different than what the author thinks and claims it is measuring. [...] And the code used for the claimed "lock not held" timing is complete garbage.

Részletek Linus reakciójában itt és itt.

( pepo v | 2020. 01. 06., h – 14:33 )

A net tele van bátor kontárokkal. Szeretem, ha koppannak az ilyenek.

READY.
󠀠󠀠‎‏‏‎▓

( SPYFF v | 2020. 01. 06., h – 15:03 )

ezen jót mosolyogtam: "I repeat: do not use spinlocks in user space, unless you actually know what you're doing. And be aware that the likelihood that you know what you are doing is basically nil."

meg ezen is: "You might even see issues like "when I run this as a foreground UI process, I get different numbers than when I run it in the background as a batch process". Cool interesting numbers, aren't they?"

Örömmel látom, hogy a PC-bohócok által majdnem átnevelőtáborba üldözött Linus kezdi visszanyerni régi formáját, elhagyta az erőszakmentes kommunikációs bullshit tanfolyam baromságait és kezd magára találni újra :D

trey @ gépház

Azért az is ember és munkahely függő. Én például saját főnököm által írt több éves kódot szoktam gyakran felhozni, hogy felesleges és hülye dolgok vannak benne. Mindezt a főnökömnek. Aki ezen nem sértődik meg, hanem ő maga is belátja, hogy igen, amit anno írt az nem mindig állja már meg a helyét. Elfogadja és kész, meg hangoztatja is ,hogy ha ilyen kód van, amit lehet csinosítani/gyorsítani, akkor nyugodtan.

Nem sértődés van ebből, mint a PC-k esetén.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

A magyar nyelv hálistennek bővelkedik normális, paraszt-bunkó stílust nélkülöző szavakban, amikkel szintén el lehet magyarázni valamiről, hogy rossz. Például add elő a munkahelyeden a "színtiszta szemetet gyártottál" műsort. Vagy bárkivel, élőben. Twitteren könnyű előadni a parasztot. Egyesek még meg is védenek. Szerintem az hogy szükségtelenül nem parasztkodok másokkal nem azért teszem mert PC vagyok és féltem a lelki világát, hanem mert ezt tartom normális  viselkedésnek. A twitteres őrjöngés sajnos teljesen napi divat lett.

Egy csomó hibás feltételezés van már a kérdésben is. Feltételezed, hogy a kód egy rakás szar, feltételezed, hogy sértődős a másik ember, feltételezed, hogy egyáltalán kell valaminek nevezni. Lásd felettem Gaab válaszát: a jelzők nélkül Linus válasza teljesen korrekt.

Neked volt már, hogy szar munkát végeztél, és beszólt a főnök vagy kolléga? Én pl. elfogadnám, ha tényleg rossz, de a jelzőket nem, csak az előremutató kritikát, hogy hogyan lehetne jobbá tenni. Ugyanakkor ezt nem nevezném sértődésnek, inkább kulturális kérdés egymás tisztelete.

Sajnálatos, hogy egy elsősorban informatikai fórumon a PC nem a Personal Computer rövidítése.

Sajnálatos, hogy a mai világban a PC (nem a Personal Computer) fontosabb mint a C (nem a programozási nyelv).

Sajnálatos, hogy ha egy noname valaki próbálja bemocskolni a már ~30 éves édes gyermeked, akkor elnézést kellene kérni, hogy esetleg te IS kellemetlen szavakat mersz használni.

Neked volt már, hogy szar munkát végeztél, és beszólt a főnök vagy kolléga?

20 év alatt nem emlékszem ilyenre. Inkább elismerő díjakat (pénzmag jutalommal) szoktam kapni. Vagy vagy 6, de ki számolja? Egyszerűen nem szoktam szar munkát végezni.

inkább kulturális kérdés egymás tisztelete.

Valahol ott lesz a probléma, hogy te tiszteletlenségnek veszed, ha megmondják neked a szarodra, hogy szar, más meg őszinteségnek. Ha nem tiszta miről beszélek, olvasd el még egyszer azt, amire válaszoltál. Abból a feltevésből indultam ki, hogy szart csináltál.

trey @ gépház

Már vagy 3 tucat kisebb-nagyobb pénzes bónuszt kaptam 5 év alatt, de ez nem jelenti azt, hogy én vagyok mr. tökéletes.

Egyrészt azt kell látni, hogy a jó munka néha szubjektív, nem lehet mindent objektíven mérni. Másrészt tegyük fel, hogy gyártok valami "szart". Lehetséges reakciók:

* Ez egy rakás szar: szubjektív, hasznavehetetlen, bunkó

* Ez egy rakás szar, amúgy azért, mert X, Y, Z: ez már használható, de még mindig bunkó és tiszteletlen (ez Linus a témaindítóban)

* Ezen az nem jó/azt kellene javítani, hogy X, Y, Z: teljesen tényszerű, ebből szokott kialakulni egy konstruktív párbeszéd (nézd csak, megmondták, hogy valami nem jó, de mégse tiszteletlen módon, nem nem jelzőkkel illetni)

* Ez szuper jó, de esetleg még lehetne módosítani, hogy X, Y, Z: ez már nem őszinte, átesik a ló túloldalára (a PC-skedést képzelem így el)

Technikai érvek felvetése önmagában sosem tiszteletlen. Ami efölött van, pl. jelzők, az már lehet az.

ez nem jelenti azt, hogy én vagyok mr. tökéletes.

Senki nem állított ilyet. Óriási a szakadék a tökéletes vagyok, rendes munkát adok ki a kezemből és a szart csináltam közt. 

Ez egy rakás szar, amúgy azért, mert X, Y, Z: ez már használható, de még mindig bunkó és tiszteletlen (ez Linus a témaindítóban)

Megint másról beszélsz. Ez a kóder írt valamit, amihez fingja sem volt és amit írt, az is rossz volt. Utána telesírta vele a netet. Szerinted erre mit kellett volna írni? Most ahelyett, hogy a kritikát megfogalmazót okolod (manapság ezt szokott lenni a csapásirány) mi lenne, ha a problémáról beszélnél, vagyis arról, hogy az illetőnek mit kellett volna csinálnia. Egy kis önvizsgálaton kívül. Az nem volt tiszteletlenség, hogy tények ellenőrzése vagy szakmai tudás hiányában a tények ellenőriztetése nélkül beleírta az internetbe, hogy a Linux scheduler rossz?

trey @ gépház

Szerintem nem volt teljesen rossz, amit a kóder írt. És a blog címe, hogy milyen rossz az ütemező, szintén nem szerencsés, habár nem olyan szint, mint Linusé, de jobb lett volna pl. hogy nem optimális.

Kicsit csúsztatás, hogy a kritikát megfogalmazót okolom. A kritika 95%-ban korrekt, kritizálni hasznos és muszáj is. Csak a plusz jelzőkkel volt gondunk, mással nem.

Vegyük úgy, a súlyozás már túl szubjektív lenne. De az egyszeri olvasó akkor is Linuson fog jobban kiakadni, mert az ő pozíciójában kéne óvatosnak lennie (ő a rendszer arca, meg meg is ígérte). De felőlem Linus is azt csinál, amit akar, nem leszek jobban vagy kevésbé Linux hívő.

Ha egy random blogger beszél így, kb. senkit nem érdekel (mondjuk pont ez a téma ellenpélda, de úgy általában). Ha Linus, az bejárja a világsajtót. Hiába nézik el neki a szűk belső körben, ha egyszer a pénzt adó cégek vagy az SJW-k kicsinálják, az nekem mint júzernek is rossz lesz. De ez az élet minden területén megvan, minél több ember figyel a szavadra, annál jobban kell vigyázni, mit mondasz, a szavaknak nagy ereje lehet, nézd meg pl. kik és mekkorát buktak kikerült hangfelvételek miatt, amikor nem vigyáztak annyira.

Pedig itt a culture fit is egy értékelési kategória a felvétel során :). Az a baj, hogy a rakás fos önmagában semmit sem ér, egy meritokráciában érvelni kell, de ha már vannak érveid, akkor a fosozás nem ad előnyt, inkább hátrányt. Amúgy persze hangzik el ilyen néha, inkább szóban, mint írásban és inkább viccből, mint komolyan, olyan kontextusban, ahol tudjuk, hogy a másik ember veszi a lapot ([gonosz]vagy nincs jelen[/gonosz]). A default egymás iránti tisztelet az egyik fő oka, amiért szeretem a munkahelyem. Engem a technikai érveken kívüli, akár pozitív, akár negatív szófosás inkább stresszel. És mivel ez így jól működik, ugyanígy állnék hozzá bármelyik jövőbeli munkámhoz és open source projekthez is.

Abból indultunk ki, hogy akkor mondjuk ki, hogy szart csinált, ha valaki szart csinált. Ha ezt megmondom neki, akkor mit csinálna?

( ) kirúgna, mert igazat mondtam

( ) hátrányos helyzetbe hozna, mert igazat mondtam

( ) gyerekes módon nekiállna a stíluson vitatkozni (terelés) és nem a problémáról beszélni

( ) egyéb

Első kettő esetben a munkaügyi bíróságon vitatkoznánk tovább a részletekről. A harmadik esetben azt nyerné vele, hogy a faszom nem mondaná meg neki a véleményét legközelebb (ami egyébként igaz, hisz ebből indultunk ki), ami nem tudom kinek lenne rosszabb. Nekem? Leszarom. Neki? Hogy nem kap egy inputot döntéshozóként?

Tovább?

trey @ gépház

jocoeknal ez nem fer bele a hatalmas PC kulturaba, ahol barmi lehetsz ha akarsz (gender: apache helikopter ROTFL)... :) nem hiaba irtam, hogy nem biztos, hogy tudnek ilyen helyen dolgozni ahol nem lehet megmondani az oszintet, hanem be kell csomagolni mindenfele szep cimkebe.

Nem volt kalap szar. Az illető nem mondta sose, hogy amit írt, az egy élesben futó spinlock implementáció, Linus meg számon kéri rajta. Játékfejlesztéseknél valószínű a spinlock-szerű várás, akármilyen  optimalizációval vegyítve, és az illető azt állítja, hogy a linux másképpen viselkedik egy, ilyen preparált esetben, mint akár a windows, xbox vagy ps4.

"az illető azt állítja, hogy a linux másképpen viselkedik egy, ilyen preparált esetben, mint akár a windows, xbox vagy ps4"

Másképp is viselkedik, mivel a CFS (completely fair scheduler) másképp működik, mint a Windows ütemező. Amennyire én tudom (nem biztos, hogy jól tudom), a Windows ütemező igazából nem preemptive (Win32 alatt biztosan nem az volt, és azt hiszem, még most sem az). Azaz egy végtelen ciklust soha nem fog megszakítani egy másik taszk (vagy process, vagy thread, vagy mittomén hogy hívják), amíg a másik taszk prioritása nem magasabb. Ha van magasabb prioritású futásra kész taszk, az is csak akkor fogja megszakítani a végtelen ciklust, ha interrupt történik. Vagyis Windows alatt egyszerre csak 1 végtelen ciklus futhat (nyilván minden CPU magon 1). Egy ilyen környezetben a fickó által írt mérő rutinok véletlenül ugyan, de működnek.

Linux alatt a CFS fair, azaz nem hagy taszkokat "éhezni". Egy végtelenciklustól a CFS akkor is elveheti a procit, ha már túl sokáig futott, vagy van olyan nem magasabb prioritású másik taszk, ami meg már túl rég óta nem futott. Ez az igazi preemptive ütemezés. Vagyis egyszerre több végtelenciklus is futhat egy procin, az alacsony prioritásúak nyilván sokkal kevesebbszer fognak majd futni. Ebben a környezetben pedig a fickó által írt rutinok vagy működnek, vagy nem. Pontosan azt teszik, amit Linus írt: a környezettől függő random időket fognak mérni.

Ha a fickó a játékaiba írt egy OS absztrakciós interface-t, amit a játékokban levő közös kód használ, és amit minden OS-re (Windows-ra, Linux-ra, Xbox-ra) újraírnak, és azt a bemutatott elvek alapján írta meg, akkor ne csodálkozzon, hogy másképp működnek a játékai Liux-on, ugyanis a Linux-os interface-e szar, azaz "garbage".

Nem olvastál figyelmesen. Win32 alatt (tehát user space-ben) ha indítasz két végtelen ciklust azonos prioritáson, akkor csak az egyik fog futni. Linux alatt mindkettő felváltva. Azaz a Linux tényleg preemptive, a Win32 meg csak amúgy félig-meddig. Win32 óta nem csináltam ilyet, de a hirtelen elém került doksik alapján a mostani Windows ütemező is így működik.

Hm. Most próbáltam Win7 alatt, és valóban rendesen preemptívnek tűnik. Mentségemre legyen szólva, hogy ilyen végtelen ciklusos földolgozást W95 alatt írtam utoljára.

Viszont akkor nem értem, hogy a játékos fickó miért nem értette Linus válaszait, hiszen a kódja Win7-en is ugyanúgy rossz, mint Linux-on, csak véletlenül másképp működik.

 

Illetve valami különbség mégis lehet. A következő gyors tesztet csináltam, Írtam egy for() ciklust, ami 1 magon 10mp-ig fut. Ezt elindítottam kb. egyidőben 5 példányban egy 4 magos i5-ön. Linux-on mindegyik példány kb. 13mp-ig futott. Win7-en viszont nagyon determinisztikusan (5-ből 5-ször) a következő történt: 3 példány lefutott kb. 11 mp alatt, 2 pedig kb. 15 mp alatt. Meg sem próbálom megmagyarázni, hogy ez miért lehet, de egyrészt furcsa, másrészt tényleg más, mint a Linux.

A különbség nálam is kijött (lásd a tesztemet), és szerintem valami olyasmi irányban keresendő a különbség, hogy a core-ok valamilyen csoportokba vannak szervezve, és "indok nélkül" a core csoportok között nem akar processzt átmozgatni a Windows (pl. NUMA access miatt vagy ilyesmi). A scheduling így csak a core csoporton belül fair, cserébe viszont gondolom meg van spórolva a cache elvesztése.

Disclaimer: ez csak tipp, igazából nem tudom, hogy mi történik valójában.

Ja, tényleg: hyperthreading? Gondolom olcsóbb ugyanannak a magnak a másik threadjére váltani, mint másik magra váltani, és ezt láthatjuk. Nálam ez lehet, a proci "Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz", ami a leírások alapján tud hyperthreadinget, de csak 1 NUMA node-ja van.

Ez egy WSL (Windows Subsystem for Linux), Windows 10 Home-on futtatva:

[zmezei@jane ~]$ for i in {1..5}; do while :; do true; done & done
[1] 725
[2] 726
[3] 727
[4] 728
[5] 729

Az eredmény ilyen egy top-ban:

top - 22:00:24 up 17 min,  0 users,  load average: 0.52, 0.58, 0.59
Tasks:  11 total,   6 running,   5 sleeping,   0 stopped,   0 zombie
%Cpu0  : 25.0 us,  0.0 sy,  0.0 ni, 75.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 75.0 us,  0.0 sy,  0.0 ni, 25.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 26.3 us,  0.0 sy,  0.0 ni, 73.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 75.0 us,  0.0 sy,  0.0 ni, 25.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu8  : 12.1 us,  6.1 sy,  0.0 ni, 81.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu9  :  3.0 us,  8.0 sy,  0.0 ni, 89.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu10 : 12.0 us,  0.0 sy,  0.0 ni, 88.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu11 :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  16336.2 total,   9413.2 free,   6699.0 used,    224.0 buff/cache
MiB Swap:  49152.0 total,  49152.0 free,      0.0 used.   9506.6 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  725 zmezei    20   0   15516    528    328 R 100.0   0.0   2:56.34 bash
  726 zmezei    20   0   15516    532    332 R 100.0   0.0   2:56.35 bash
  727 zmezei    20   0   15516    528    328 R 100.0   0.0   2:56.41 bash
  728 zmezei    20   0   15516    532    332 R 100.0   0.0   2:56.36 bash
  729 zmezei    20   0   15516    528    328 R 100.0   0.0   2:56.35 bash
    1 root      20   0    8892    308    276 S   0.0   0.0   0:00.01 init
    6 root      20   0    8896    212    172 S   0.0   0.0   0:00.00 init
    7 zmezei    20   0   15516   2680   2492 S   0.0   0.0   0:20.38 bash
  717 root      20   0    8896    212    172 S   0.0   0.0   0:00.00 init
  718 zmezei    20   0   15516   2576   2492 S   0.0   0.0   0:00.01 bash
  721 zmezei    20   0   17152   2024   1432 R   0.0   0.0   0:00.20 top

Erre pedig:

[zmezei@jane ~]$ for i in {1..13}; do while :; do true; done & done
[1] 741
[2] 742
[3] 743
[4] 744
[5] 745
[6] 746
[7] 747
[8] 748
[9] 749
[10] 750
[11] 751
[12] 752
[13] 753

Ilyen:

top - 22:02:24 up 19 min,  0 users,  load average: 0.52, 0.58, 0.59
Tasks:   4 total,   1 running,   3 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.4 us,  0.2 sy,  0.0 ni, 99.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
top - 22:04:47 up 22 min,  0 users,  load average: 0.52, 0.58, 0.59
Tasks:  19 total,  14 running,   5 sleeping,   0 stopped,   0 zombie
%Cpu0  : 97.9 us,  2.1 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 99.8 us,  0.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  : 97.9 us,  2.1 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  : 99.4 us,  0.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu8  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu9  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu10 :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu11 :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  16336.2 total,   9435.0 free,   6677.2 used,    224.0 buff/cache
MiB Swap:  49152.0 total,  49152.0 free,      0.0 used.   9528.4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  741 zmezei    20   0   15516    536    316 R 100.0   0.0   1:17.59 bash
  753 zmezei    20   0   15516    536    316 R 100.0   0.0   1:13.50 bash
  742 zmezei    20   0   15516    540    320 R 100.0   0.0   1:18.32 bash
  748 zmezei    20   0   15516    536    316 R 100.0   0.0   1:15.99 bash
  747 zmezei    20   0   15516    536    316 R 100.0   0.0   1:12.51 bash
  749 zmezei    20   0   15516    536    316 R 100.0   0.0   1:18.33 bash
  752 zmezei    20   0   15516    536    316 R 100.0   0.0   1:12.94 bash
  745 zmezei    20   0   15516    536    316 R 100.0   0.0   1:17.53 bash
  743 zmezei    20   0   15516    536    316 R  82.6   0.0   1:06.98 bash
  746 zmezei    20   0   15516    540    320 R  82.4   0.0   1:05.79 bash
  744 zmezei    20   0   15516    540    320 R  82.0   0.0   1:06.40 bash
  751 zmezei    20   0   15516    536    316 R  81.0   0.0   1:04.37 bash
  750 zmezei    20   0   15516    536    316 R  79.6   0.0   1:02.54 bash
    1 root      20   0    8892    308    276 S   0.0   0.0   0:00.01 init
  717 root      20   0    8896    212    172 S   0.0   0.0   0:00.00 init
  718 zmezei    20   0   15516   2620   2544 S   0.0   0.0   0:00.02 bash
  736 root      20   0    8896    212    172 S   0.0   0.0   0:00.01 init
  737 zmezei    20   0   15516   2608   2428 S   0.0   0.0   0:00.01 bash
  740 zmezei    20   0   17152   2012   1424 R   0.0   0.0   0:00.01 top

Pár perc után ps kimenetéből látszik, hogy nem teljesen fair az ütemezés, valóban (lásd a TIME oszlopot):

[zmezei@jane ~]$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   8892   308 ?        Ssl  21:42   0:00 /init
root       717  0.0  0.0   8896   212 tty2     Ss   21:54   0:00 /init
zmezei     718  0.0  0.0  15516  2620 tty2     S    21:54   0:00 -bash
root       736  0.0  0.0   8896   212 tty1     Ss   22:02   0:00 /init
zmezei     737  0.0  0.0  15648  2764 tty1     S    22:02   0:00 -bash
zmezei     755 97.1  0.0  15516   532 tty1     R    22:08   3:56 -bash
zmezei     756 92.9  0.0  15516   532 tty1     R    22:08   3:45 -bash
zmezei     757 88.7  0.0  15516   536 tty1     R    22:08   3:35 -bash
zmezei     758 91.2  0.0  15516   532 tty1     R    22:08   3:41 -bash
zmezei     759 99.8  0.0  15516   532 tty1     R    22:08   4:02 -bash
zmezei     760 92.1  0.0  15516   536 tty1     R    22:08   3:43 -bash
zmezei     761 87.6  0.0  15516   532 tty1     R    22:08   3:32 -bash
zmezei     762 91.0  0.0  15516   532 tty1     R    22:08   3:41 -bash
zmezei     763 89.2  0.0  15516   532 tty1     R    22:08   3:36 -bash
zmezei     764 93.3  0.0  15516   532 tty1     R    22:08   3:46 -bash
zmezei     765 83.5  0.0  15516   532 tty1     R    22:08   3:23 -bash
zmezei     766 89.8  0.0  15516   532 tty1     R    22:08   3:38 -bash
zmezei     767 85.8  0.0  15516   532 tty1     R    22:08   3:28 -bash
zmezei     770  0.0  0.0  16816  1936 tty2     R    22:12   0:00 ps aux

Ennek ellenére egyáltalán nem az van, hogy valamelyik processz ne kapna processzoridőt. Nem mellesleg ez az egész futott, miközben megírtam ezt a kommentet, úgyhogy nem állt meg tőle a rendszer, mint a szög...

Ezek alapján szerintem nincs igazad abban, hogy hogy működik a Windows ütemezője.

Amikor a tesztedben csak 5 szál fut, akkor olyasmi történik, mint amit én láttam az eredeti tesztemben, amikor már csak 2 szál futott. Az 5-ből 3 elfut 1-1 magon, a maradék 2 pedig 4 magra van szétdobva. Nálam, amikor már csak 2 szál futott, azok 2-en mind a 4 magot használták.

A top az elmúlt X másodpercre átlagolja a CPU mag kihasználtságát. Ha mondjuk X=2, és 0.5 sec-et az egyik processzormagon, 1.5 sec-et meg a másik processzormagon futott ugyanaz a processz, akkor 25%-ot és 75%-ot fog jelezni. Ez még ugyanúgy 100%, csak közben a scheduler úgy döntött, hogy másik magra akarja rakni a processzt. (Ami meg nyilván azért van, mert más is futott a gépemen, pl. egy Chrome, egy Slack, egy nvidia driver telepítő, 3 google drive sync meg egy rakás más cucc, aminek kellhetett még CPU, és simán lehet, hogy valamiért optimálisabb volt a végtelen ciklust arrébb rakni.)

"ahol nem lehet megmondani az oszintet, hanem be kell csomagolni mindenfele szep cimkebe."

Elvárás, hogy megmondd az őszintét, akár a főnököd főnökének is. Nem muszáj szép címkébe csomagolni (én nem szoktam), de csúnya körítés se kell hozzá (annak tényleg lehet negatív következménye).

Nem mondtam ilyet. Suboptimal, inefficient, slow, technical debt, overcomplicated, overengineered, unnecessary, ezekkel semmi gond nincs. A garbage és crap már egy kicsit az elvárt szint alatt van. És van ettől még rosszabb is, horrible fucking mess, idiotic rambling, have you lost your fucking mind... De ne hidd azt, hogy van itt egy céges szótár a jó és rossz szavak listájával. Ez ilyen társadalmi konszenzus. Szerintem egy részletesebb értelmező szótárban is meg lehet nézni a szavak színezetét, melyikhez van odaírva, hogy szleng/obszcén/informális.

Az a baj, hogy egyesek úgy gondolkodnak, ahogyan az SJW-k. Baromira nem érdekli őket, hogy mi a szakmai háttér, hanem általánosságban foglalkoznak Linus stílusával. Pedig a szakmai háttér az az, hogy olyan kódot, amit az állítólagos játékfejlesztő bemutatott, csak óvodás ír, vagy idióta. Nem is az a baj, hogy butaságot írt, hanem az, hogy óriási publicitást csinált neki. A "garbage" és a "crap" nagyon visszafogott jelző arra a kódra.

A levlistában egyébként utána elő is jött egy elvileg fejlesztő SJW aki számonkérte Linus-t a stílusa miatt, meg kérte, hogy normális release metódusra álljanak át...

Utána többen ki is jelentették, hogy igazából egyik oldalról sem érzik, hogy bármi sértő lenne a levelezésben.

 

Lehet sokaknak nem tetszik a garbage és crap kifejezés, de még mindig finom jelzők. Lehetne simán f*cking sh*t is, akarom mondani hugging sh*t.

 

Meg tegyük hozzá, hogy Skarupke nem is sértődött meg rajta. Értette, hogy azokat a jelzőket miért használja Linus és értelmes hangnemben tovább folyt a beszélgetés. Akik ezen felhúzták magukat nem is közvetlen résztvevői a beszélgetésnek, ugyanis az Linux és Skarupke között folyt. Egyikőjük sem sértődött meg a másikon.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Munkahelyen, azaz ahol voltaképpen mindenkinek az az érdeke, hogy a mindenki jól végezze a feladatát, teljesen igaz, amit Jocó ír. Vegyük azért észre, hogy Linus és a blogger viszont nem ilyen relációban vannak egymással, és Linusnak igen kevés érdeke fűződik ahhoz, hogy később is gördülékenyen együtt tudjon működni az illetővel. Ellenben a beszólás hatására egész sokan elolvasták Linus magyarázatát is, amitől akár okosodhattak is. (Vagy nem.)

Amúgy kedvenc védekezésem főnöktől, amikor szembesítették ~10 éves kódjával: "Fiatal voltam, kellett a pénz!"

És kedvenc beszólásom Linustól:

We do not trust BIOS tables, because BIOS writers are invariably totally incompetent crack-addicted monkeys. If they weren't, they wouldn't be BIOS writers. QED.

 

Gyanús, hogy vagdalkozik, meg 1900 szavas bullshiteket ír, nem hiteles. Olyan, mintha Newton törvényeit szemétnek neveznénk, mert nincs benne idődilitáció. :) 

A srác mért valamit, ami Linus szerint egy rossz random generátor, viszont a játékosok meg ezt érzik, ez a végfelhasználói élmény. Nem hiszem, hogy a játékosokat érdekli Linus hosszú, általános, és igaz magyarázata.

Viszont bevallom én nem tudtam hogy a spinlockokkkal ennyire meg lehet szívni, meg még sok más érdekes dolog is volt a poszban, szóval örülök hogy ilyen hosszan ecsetelte a dolgot. Jó lenne elolvasni ezt (https://arxiv.org/abs/1701.00854) és képbe kerülni rendesen a témában, de pont jó hogy itt Linus működési szempontból leírja ezeket a bonyolultabb mechnaizmusokat.

Szerintem ezt nem is cáfolja a srác. Inkább azt mondja, hogy ez is hasznos információval szolgálhat. Ha a mérési táblázatok helyesek, akkor valahogy mégis csak az van, hogy a srác által kitalált konstelláció a linunxon rosszabb teljesítményt nyújt, mint a windowsos. És mivel a userspace spinlock szerű förmedvények gyakoriak a játékoknál, ez a konstelláció is érdekes lehet.

Ezt is írta a csávó: "the Windows scheduler is pretty good though".

Aki próbált már többszálas programot írni Windows API-ra, annak tisztában kell lennie az ellenkezőjével. Én a fönti mondatnál tovább nem is vagyok hajlandó olvasni az egészet, és tökéletesen biztos vagyok benne, hogy amit Linus írt, annak minden betűje helytálló. (Sajnos kicsit mégis továbbolvastam, és később is találtam benne butaságokat. Linus első pár kritikáját is elolvastam, és azok korrektek.)

Alapvetően én sem bírom a bunkó stílust és elég stresszes tud lenni.

Mindazonáltal ha tényleg baromság amit csinál valaki, amiben nem valami rossz, meg lehetne jobb, hanem hulladék az egész (akár koncepcionálisan, akár megvalósításban) akkor meg kell mondani, azzal együtt hogy miért, helyette hogyan kéne és tanulni belőle. Persze mindezt kulturáltan, de nem köntörfalazva, hogy ehh-öhh himi humi ez így nem az igazi izé. 

Ha szemét a minősége, akkor minek nevezze? Én is annak nevezek dolgokat, amiket arra érdemesnek találok.

Viszont amennyiben lehetséges, akkor az észhez térítő fröcsögés után a megmagyarázásra/javításra/helyretételre célszerű törekedni. Itt Linus is így járt el.

 

„A jó pap is holtáig tanul.”

Valószínűleg ezek a dolgok a generációbeli különbségekből jönnek. Akik jártak ipari iskolába, vagy esetleg voltak katonák (Elnézését kérem kedves honvéd úr/úrhölgy, megtenné, hogy a gépkarabélyt csőre töltve és kibiztosítva nem fordítja maga .... ratatataatatatta .... eh, mindegy, vigyék el vs. Mi a faszt csinál, kopasz?!?) , azok megszokták az egyenes (és hatékony) beszédet. Akik meg Waldorf-ba jártak, azok besírnak, ha találkoznak egy előbbivel.

trey @ gépház

Egyenes beszéd: menekülj Pista, omlik a bánya! Fölöslegesen negatív: takarodj innen Pista a jó kurva anyádba, mert omlik a bánya! Fölöslegesen pozitív: kedves Pista, esetleg gondolkodj el azon, hogy kimész, mert van rá esély, hogy beomlik a bánya.

Lehet keménykedni, de az egyenes beszédnek nem kell bunkósággal párosulnia. Pont akkor lesz kevésbé lényegre törő, ha az is van benne. És adott környezetben az illedelmes fölösleges köröket se várja el senki.

Ez már kicsivel jobb. De ne ragadj le itt, a jelzőktől mentes kritika hatékonyabb, egyben lényegre törőbb és kifogástalan is. Tök fölösleges ragozni. "A te kódod nem a lock idejét méri, mert ...". Egy céges belső vagy publikus code reviewban ugyanezt írnám. Nem akarok más lelkébe taposni, neki is rossz, meg utána nekem is. De ez nem puhányságot jelent, mert a technikai érvekben nincs kompromisszum, még csak nem is fogom őket lassabban adagolni.

Ja, csak ez nem munkahely, nem munkatársai egymásnak, nem is ismerik egymást és az egyik fikkantással kezdett, ráadásul melléfogott. Tehát egyáltalán nem az a helyzet, amikor te egy munkatársadnak írsz egy céges rendszerben, mert ott kötnek a munkahelyi írt és íratlan szabályok.

trey @ gépház

Szerintem nagy szükség van mindkét fajta hozzáállásra. Én is próbálok jóindulatúan fordulni mások kódjához, hibáihoz. Többnyire azt tapasztalom, hogy ha én írok szar kódot, vagy csinálok valamit szarul, arra is jóindulatúan, türelmesen mondják el, hogy nem így kellett volna. Viszont sokkal izgalmasabb, hogy vannak akik Linushoz hasonlóan jól leb*sszák az embert néha, másképp elég tyúkszaros, unalmas lenne az ipar :D

Aki úgy általában megsértődik már a kritika tényén, abból jó fejlesztő nem lehet, csak snowflake. De egy code review-ban nem kell semmi sértőnek lennie. És nem akarok nagyon nyelvészkedni, de angolban jobban átjön a különbség: "Criticism looks for flaws in the writer as well as the writing/Critique addresses only what is on the page".

( uid_4656 v | 2020. 01. 07., k – 09:10 )

Szerkesztve: 2020. 01. 07., k – 09:13

Úgy látom, hogy Linusnak már megint fáj, hogy vannak felhasználói, akik nem értenek annyira a dolgokhoz, mint ő. Illetve pontosabban: más dolgok fontosabbak a felhasználók számára, mint Linus számára.

És részben beismeri, hogy valójában tényleg szar az implementáció és update érett...

smeuletz (alexsmeu.delete@this.yahoo.com) on January 6, 2020 9:11 am wrote
> Well, in his post Linus Torvalds himself says: "End result: sched_yield() is basically historical garbage"
> So, since it rarely has any good use, and can only be used with a realtime scheduler, it should
> be deprecated and later removed and a new header (eg: sched_realtime.h) should be added, with a
> new sched_realtime_yield() API, which would return error if the scheduler is not realtime.
> And thus, the API would be updated to reflect reality and minimize the chance for erroneous usage.

( coco | 2020. 01. 07., k – 10:05 )

Mondjuk az érdekelne, hogy aki szerint szemét amit kiadott a kezéből a srác, az végigolvasta-e a cikkét esetleg végigment-e a thread-en ahol Linus maga is bevallja hogy némi update ráférne a dologra.

Vagy ha Linus azt mondja hogy szar akkor az tényleg szar.

Én nem azt mondom, hogy szemét, amit csinált a srác. A kód minőségére nem tudok mit mondani, mert ahhoz nem értek... DE:

  • Skarupke írja is, hogy kipróbált több ütemezőt és más eredményeket kapott, ami természetes
  • A spinlock-ra írt egy saját megoldást, amit userspace-ben használt
  • Hozzászólások között elismeri, hogy ez volt az első alkalom, hogy Linux-os ütemezővel kellett dolgoznia (úgy, hogy igazából nem is az ő feladata volt, csak kíváncsiságból tesztelt)
  • A többi hozzászólásban már többen felhívják a figyelmét rá, hogy a spinlock nem userspace-be való. Van kernel szintű megoldás rá, azt kell használni és nincs ilyen probléma.
  • A blogban kb nyíltan kinyilvánítja, hogy hát a Windows ütemező jobb, mert ott nem tapasztaltak ilyeneket. Hát köszönjük, minden ütemező más felhasználásra van optimalizálva
  • Kb mondhatjuk, hogy az egymás munkájának szitkozódását nem Linus kezdte. Elég csak a blog címét nézni: "Measuring Mutexes, Spinlocks and how Bad the Linux Scheduler Really is". Ez kb ugyanaz, mintha kijelentette volna, hogy szar az ütemező. Tehát még örülhet is, hogy Linus visszafogottabban fogalmazta meg a dolgot.
  • Skarupke válaszában felveti a problémáit, de mivel nem ért hozzá teljesen, így túlságosan egyszerűen kezeli a dolgokat és olyan dolgokhoz hasonlítja az egészet, ami teljesen más megoldásokat kívánnak, lásd a PlayStation és Xbox, hogy ott ilyen nincs. Linus erre tőle telhetően normálisan elmagyarázta a dolgokat, hogy mi a probléma a felvetéseivel és a leegyszerűsített gondolkodással. Egy konzol esetén az az optimális, hogy kb minden más folyamat háttérbe szorul és a játék élvezi a kiemelt pozíciót, de egy Linux disztribúcióban lévő kernel (ha már Stadia), elsősorban nem ilyen felhasználásra van kihegyezve. Nem tudom a Google csinál-e módosítást ezért. Ott háttérben minden másnak is futnia kell. Ahogy Linus is írja, hogy ha egy processz megfogja a lock-ot, amíg az neki kell az nagyon rontja a rendszer használhatóságát. A példájával élve játék közben jön egy antivírus, ami végig akarja ellenőrizni a rendszert miközben játszol... Ha úgy működne az ütemező, ahogy Skarupke véli, akkor az av minden erőforrást elvenne a játéktól, azt játszhatatlanná téve.
  • Ahogy Skarupke is írja: "I hope to have convinced you to avoid spinlocks, even for very short sections." Ezzel az a legszebb, hogy Linus is pont ugyanezt fejtette ki. Illetve a dokumentációban is ez szerepel:
    "Avoid calling sched_yield() unnecessarily or inappropriately (e.g., when
    resources needed by other schedulable threads are still held by the
    caller), since doing so will result in unnecessary context switches,
    which will degrade system performance."
  • "End result: sched_yield() is basically historical garbage" ahogy Linus fogalmazta. Tehát igen, elismerte, hogy a kernelben is van olyan ami már szemétre való, de ahogy egy későbbi levelében írja, a Linux fejlesztése azon az irányon marad, hogy ha lehetséges, akkor ne törjenek meg semmit, hogy ha esetleg valaki mégis használná az adott API-t.

 

Így most ennek a témának a felröppenése kapott egy kis visszhangot ezért most mindenki rászállt a Linux ütemezőjére, aminek köszönhetően javítgatnak rajta ha kell.

 

De az egész összefoglalva:

  1. Skarupke, használt egy olyan kernel funkciót ami dokumentációban írja, hogy ne használják.
  2. Nem tetszett neki az eredmény.
  3. Sírt egyet a blogjában róla
  4. Megkapta a választ, hogy hülyeséget csinált

Kell még ezt ragozni?

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Hát ez az hogy nem, ezért nem értem hogy miért szaroznak egyesek, azaz érzésem hogy van egy ilyen attitűd hogyha Linus mondja hogy szar akkor az csak szar lehet (és igen ettől még lehet szar a munkája, szerintem egyébként nem, de igen van benne hiba)... Igen nem volt szerencsés, hogy a srác azt a címet adta a cikknek ami, de egyesek olyan nyíltan fikázzák itt mások munkáját mintha részletekbe menően körüljárták volna a témát... Ebből így lett egy flame, merthogy kevés szakmai vitát vélek felfedezni mind itt, mind pedig a linkelt threaden.

Egyébként csakhogy a pozitív hozadékot is említsük meg, Linus is elismeri hogy ennek "hála" valószínűleg a téma több figyelmet fog kapni.

"Maybe this discussion ended up at least making more people aware of this all.."

Ha más nem talán ennyi hozadéka lett a "szarozásnak"...

Kb erről van szó:

Szar a plédakód? - Igen

Mélyebb Linux scheduler hozzáértés nélkül kezdett szakérteni a poster? - Vessetek a mókusok elé, ha nem.

Nem lehet semmi hasznosat szólni az eredménnyel kapcsolatban? - Vitatható, tény hogy ez esetben Linusnak nem volt feladata hogy konstruktív legyen.

Rossz és hatásvadász volt a blogpost címadása ami felhúzta Linust - Teljes mértékben. De a reakciód nem a másik felet minősíti hanem téged.

Egy masszívan interaktív alkalmazást szerencsésebb lenne realtime prioritással szimulálni ami, ahogy én kivettem a tesztekből teljesen out of scope volt.

Lehetett volna ez egy építő jellegű beszélgetés kezdete? - Egy épeszűbb világban mindenképp. De a mai módi amikor mindenki by default védekező állást vesz fel (igen, ez a közösségi média mechanizmusainak a mellékterméke, legalább részlegesen) ez túl idealista elvárás.

"Dummies guide to create a lose-lose situation". Legalábbis a blogpost hatásvadász címadása és Linus reakciója erre állította be a nyitóhangulatot. Nekem nagyon hiányzik a régi open source közösség hangulata, persze sok minden (beleértve a közösség összetételét) változott időközben.

Nyilván, ez csak a saját naív véleményem és én  - másokkal ellentétben - szoktam tévedni. :)

( khiraly | 2020. 01. 07., k – 15:10 )

Apropo PC:

Most hallgattam egy eloadast ahol a Man in the middle attackot, Person in the middle attacknak mondta az eloado:)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....