Latence mutex vs. spinlock v Linuxu

Malte Skarupke v článku sdílí svá měření latence přístupu ke kritické sekci pomocí mutexů a spinlocků v závislosti na použitém plánovači v Linuxu. Doporučuje vyhýbat se spinlockům. Diskuze proběhla přímo pod článkem nebo také na Hacker News.

2.1.2020 19:33 | ʚĭɞ 🍉 | Zajímavý článek

Komentáře

[citanus]

Pekny cteni. Diky

[Michal Kubeček]

Z textu zprávičky (a bohužel ani z úvodu článku) to není moc zřejmé, ale autor se zabývá implementací spinlocků a mutexů v userspace, a to se silným důrazem na programování her. A jak je vidět z diskuse (ale místy i ze samotného článku), chybí mu porozumění tomu, "co je pod tím", takže jeho přístup je spíš empirický (tenhle scheduler má prý být lepší, tak to zkusíme přepnout a pustit benchmark znovu).

[Freshmouse]

No od Kubečka jsme to potřebovali vysvětlit. BTW víš vůbec, o čem mluvíš?

[dustin]

Vždyť má pravdu, stačí si přečíst komentáře.

[_]

To je právě to, co mě na Kubeckovi sere. Ničemu nerozumí, ale neustále papouskuje co si přečte. Mnohdy nezna ani význam slov, která píše.

[kralyk z abclinuxu]

Co to plácáš prosimtě, Kubeček je systémovej inženýr mj. s commitama v kernelu atd. Fakt není důvod si myslet, že nerozumí těm slovům...

[MadCatX]

I kdyby se MK snad někdy mýlil, v tomhle případě má pravdu. Asi nejpikantnější je, že ty různé schedulery benchmarkoval na různých verzích jádra. CFSko na distribuční 4.15 (Ubuntu 18.04), ty další na nějakých 5.něco, sám si prý není jistý. Že si v jednom případě zřejmě zapomněl přebuildit nVidií blob a celý GS se mu pak vykresloval přes LLVMpipe mu na kredibilitě taky moc nepřidává. Pěkně to v tom Googlu prasí...

[hele]

#troll1

[citanus]

Jo jo, ja to z toho i tak nejak pochopil. Problematice mutexu a spin locku jsem uplne nerozumel, teda nevim jestli se to moc zlepsilo po jeho precteni, nicmene problem je to zajimavej a pekne se to cetlo : )

[MadCatX]

Osobně bych šel s kritikou ještě o kus dál. Autor totiž hodnotí schedulery podle toho, jak dobře na nich funguje jeho koncepčně nesprávný kód. To machrování s paměťovými bariérami v kódu, který nejspíš na ničem jiném než na x86_64 nikdy neběžel mi taky přijde poněkud pochybné.

[Michal Kubeček]

Mně přišla nejsmutnější ta pasáž, kterou by šlo s trochou nadsázky převyprávět jako "SCHED_RR má prý být dobré na latence … jo, latence vycházejí pěkně … ale udusí to zbytek systému … takže SCHED_RR je (nám) k ničemu". To je přesně ten "empirický přístup": místo aby se snažil pochopit, jak to funguje, k čemu by se mu to mohlo hodit a na co se to naprosto nehodí, tak to zkusí použít jako univerzální kouzelný proutek a když to tak nefunguje, tak to šmahem zamítne. S těmi schedulery je to podobné.

[Petr]

Dík za upozornění, už jsem se chtěl divit, jak se někdo obejde bez spinlocku např. v interrupt kontextu, díky tobě a některým dalším diskutujícím to můžu jednoduše pustit z hlavy a celý to ignorovat

[hele]

to můžu jednoduše pustit z hlavy a celý to ignorovat

Jinak bys?

[Petr]

jinak bych ten článek šel číst a to by byla ztráta času

[Tom K]

Myslím, že tohle to vystihuje dostatečně:
https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723

[trekker.dk]

Tyjo, až do podpisu nebylo poznat, že autorem je Linus Torvalds - zdá se, že to s tím, že nebude ošklivej na lidi, myslel vážně.

[sid]

Krasne stare casy ked "V těch dobách byli duchové odvážní, rizika vysoká, muži byli praví muži, ženy pravé ženy a malá chlupatá stvoření z Alfy Centauri byla pravá malá chlupatá stvoření z Alfy Centauri" a linus bol linus. Za dalsich 10 rokov uz ani nenapise ze je stupidny kod ale "kod co obcas nerobi to co ma"