Jaderné noviny – 3. 1. 2013: Chytřejší spinlocky a dopad na výkon (diskuse)

[Nikola Ciprich]

nazává -> nazývá

[JS]

To s temi spinlocky je fascinujici! To jsou veci, proc JN ctu rad.

[Bystroushaak]

Taky tak.

[dumblob]

No, tak na tom githubu vidim rok stary Tux3 . Zrejme tedy jde jeste o nejakou "starou" variantu. Skoda - docela me to zajimalo.

Btw ty spinlocky jsou velice zajimave - to by me jen tak nenapadlo .

[retroslava]

Kuk: https://github.com/OGAWAHirofumi/tux3/tree/temp-atomic-commit

[dumblob]

No, priznam se, ze vetev temp-atomic-commit jsem prehledl.

[lertimir]

vida, konečně filesystem přímo pro flash v jádře. Nechám si na svém flash disku v notebooku nějakých 50 GB volných a jak se dostane jádro ven tak ho zkusím. (Což ale bohužel do openSUSE 12.3 se nestihne.)

[Michal Kubeček]

V OpenSuSE 12.3 bude 3.7

[little.owl]

A jeste lepsim resenim je mit HW spinlocky ...

[Sten]

No jo, ale co uživatelé PCček? A taky je otázka, jak dobře jsou ty HW spinlocky implementované.

[little.owl]

Mam praktickou zkusenost s TI implementaci na OMAP4 a na Nextre a tam to funguje velmi dobre.

[Sten]

A bylo alespoň jedno z toho osmijádro? Ony se tyhle problémy na malém počtu jader moc neprojevují ani softwarově

[little.owl]

Tak ony se projevuji i na mensim poctu jader a pokud chcete z HW dostat maximum, zacne byt souvisejici cache management problem. Heterogenni ctyrjadro, A8 + 2xM3 s HW acceleratory + DSP, pricemz kazde jadro ma svuj nezavisly OS, pracuji nad sdilenou pameti a prenasi mezi sebou synchronne plno dat. Na HW spinlockach ted pracuji Renesas, Freescale a dalsi, takze to asi uvidime casteji, i u poli heterogennich CPU.

[little.owl]

chtel jsem napsat - u i u poli homogennich CPU.

[pc2005]

Jak ten hardwarový spinlock funguje? Je to vůbec ticket spinlock? Já jen, že v kernelu je předem neznámý a za chodu se měnicí počet ticket spinlocků.

[Michal Kubeček]

Spinlocků sice je hodně, ale těch, které jsou v danou chvíli aktivně používány, zase tak moc nebude. Těch, na které někdo čeká, bude nejvýše tolik, kolik je procesorů (minus jedna); držet jich sice může jeden procesor i víc najednou, ale z podstaty věci je lepší se tomu vyhýbat a pokud to nejde, ten počet nebude nijak vysoký. Navíc bych řekl, že pro implementaci spinlocku v procesoru to ani nebude podstatné a stačila by tabulka, který procesor čeká na který spinlock.

[pc2005]

které jsou v danou chvíli aktivně používány, zase tak moc nebude

To

#if (CONFIG_NR_CPUS < 256)
typedef u8  __ticket_t;
typedef u16 __ticketpair_t;
#else
typedef u16 __ticket_t;
typedef u32 __ticketpair_t;
#endif

je jen omezení ve zdrojácích (navíc podivné a na x86 ). Spinlocky v linuxu nemusej být se zakázaným přerušením a tedy může dojít k reschedulingu na jinou úlohu.

Těch, na které někdo čeká, bude nejvýše tolik, kolik je procesorů (minus jedna); držet jich sice může jeden procesor i víc najednou

Omezení uživatelů zámku nikde není, počet procesorů je a má být vůči implementaci spinlocků irelevantní. Spinlocky by měly fungovat nezávisle na vrstvě nad kterou běží. Rwlock například s více uživateli přímo počítá. Na MIPSu jich může být teoreticky až 2 miliardy .

ale z podstaty věci je lepší se tomu vyhýbat a pokud to nejde, ten počet nebude nijak vysoký

V obsluze přerušení se to hemží neustálými raw_spin_lock_irqsave a raw_spin_unlock_irqrestore, mezi kterými je občas nějakej printk. Všechno to může běžet na libovolném procesoru zároveň (v případě timeru i často běží). Obsluha printk pak má vlastní serializovací semafor. Přerušení jsou často realizována tak, že se nastaví úloha s nižší prioritou, která teprve v normálním multitaskingu zpracuje data. Mezitím může být aktivováno jiné přerušení a/nebo dojít k reschedulingu.

a stačila by tabulka, který procesor čeká na který spinlock.

...kterou musíš při každé události (výše) modifikovat a zapsat, což povede k nějaké cache události (více procesorů v jednom cacheline)→což je stejný problém jako na začátku .

Závěr: Co jsem četl (datasheety zběžně), tak oba mícháte jablka s hruškama. V jaderných novinách je popisovanej ticket spinlock na blokaci přístupu vlákna k proměnné a v tom OMAPu je něco jako handshake/semafor přístupu k DSP, což je vlastně dost hnusná obezlička k tomu, že ty DSP asi nemají podporu read-modify-write operací. Jakmile ale člověk má podporu atomických operací po sběrnici, tak je jakýkoliv hw modul neefektivní zbytečnost. Zvláště, když úprava toho ticket spinlocku bude IMHO spočívat v druhém čítači, co odčítá od rozdílu mezi tiketem a tailem (což jsou asi dvě nebo tři instrukce a jeden registr navíc ).

[Michal Kubeček]

To … je jen omezení ve zdrojácích (navíc podivné a na x86 ). … počet procesorů je a má být vůči implementaci spinlocků irelevantní.

To u ticket locku dost dobře nejde, protože potřebujete, aby typ, který pro hodnotu ticketu používáte, byl dostatečně velký, aby mohl pojmout tolik různých hodnot, kolik je procesorů. A to je přesně význam té konstrukce, kterou jste nazval podivnou.

Samozřejmě je možné používat i jiné implementace než ticket lock, ale i u nich budete muset zajistit aspoň takovou úroveň "spravedlivosti", jako má ticket lock, jinak se vrátíte do (ne tak dávné) doby před zavedením ticket locků.

Spinlocky v linuxu nemusej být se zakázaným přerušením a tedy může dojít k reschedulingu na jinou úlohu.

Ne, to nemůže. Jakmile by k tomu došlo, máte průšvih. Nanejvýš se může stát, že zatímco task na procesoru drží spinlock, může být přerušen a obsluha přerušení si vezme jiný spinlock. To "jiný" je klíčové, jakmile by si zkusila vzít některý, který už drží přerušený task, máte okamžitě deadlock. To je právě důvod, proč existují ty různé _irq a _bh varianty, které je potřeba použít u spinlocků používaných i v obsluze IRQ nebo BH.

[pc2005]

Podivná (byl to trochu offtopic, přiznávám) proto, že Linux defaultně neběží na x86-16 procesorech a na x86-32 se stejně musí udělat lock celého 64bit přenosu po sběrnici .

Ne, to nemůže. Jakmile by k tomu došlo, máte průšvih. Nanejvýš se může stát, že zatímco task na procesoru drží spinlock, může být přerušen a obsluha přerušení si vezme jiný spinlock. To "jiný" je klíčové, jakmile by si zkusila vzít některý, který už drží přerušený task, máte okamžitě deadlock.

Souhlas. Nejen to jsem se taky snažil říct. Bohužel až v 4:40 a rozespalý :-/. Navíc mě ještě ovlivnilo to, že little.owl navrhnul řešení v OMAPu jako náhradu linuxovýho ticket spinlocku, což jsou prostě jablka s hruškama. Chtěl jsem tím taky demonstrovat to, že tvůj návrh tabulky je overkill, protože počet spinlocků není předem znám. Musel bys ty tabulky dynamicky generovat a řešit jejich aktualizaci (cache, TLB apod).

[little.owl]

Navíc mě ještě ovlivnilo to, že little.owl navrhnul řešení v OMAPu jako náhradu linuxovýho ticket spinlocku, což jsou prostě jablka s hruškama.

Vubec ne, nic takoveho jsem nenavrhl, zkreslena interpretace.

(a) HW spinlocky jsem uvadel jen jako efektivnejsi reseni problemu s nekolika vrstvami cache, vzdyt to byl ostatne i hlavni duvod celeho jejich cviceni vyvojaru kernelu a HW spinlock to resi - pristup do jejich registru neni cachovan;

(b) nevyjadroval jsem se k ticket spinlockum, ani jsem je nezminil, podobne problemy ma kazdy spinlock pracujici nad sdilenou pameti;

(c) OMAP4 a Netru jsem uvadel jen jako priklad dostupneho HW s nejakou implementaci HW spinlocku. Je jich mnohem vice od Tegry, pres nektere Picochip ci xCore. To ze jste si na OMAP4 zasedl a snazite se dokazat, ze je to k nicemu, je vas problem.

[pc2005]

nevyjadroval jsem se k ticket spinlockum, ani jsem je nezminil, podobne problemy ma kazdy spinlock pracujici nad sdilenou pameti;

Problém, že jaderné noviny se vyjadřují exkluzivně ke ticket spinlockům .

Spinlocky, jakožto jaderný synchronizační mechanismus nejnižší úrovně, jsou zdánlivě cílem nekonečných snah o zlepšení výkonu. Mechanismus ticket spinlock používáný v hlavní řadě jádra odolával těmto snahám už několik let. Nyní ale vývojáři jádra odhalili úzké hrdlo spojené s těmito zámky a snaží se přijít s vylepšenou verzí.

To ze jste si na OMAP4 zasedl a snazite se dokazat, ze je to k nicemu, je vas problem.

Není, to je jen důsledek toho, že jsem jí (pandaboard) před nějakou dobou silně propagoval (tady) a pamatuju si, že OMAP datasheety jsou podrobné a kde že je lze lehko vyhledat.

HW spinlocky jsem uvadel jen jako efektivnejsi reseni problemu s nekolika vrstvami cache, vzdyt to byl ostatne i hlavni duvod celeho jejich cviceni vyvojaru kernelu a HW spinlock to resi - pristup do jejich registru neni cachovan;

Pokud tedy mluvíš o mechanismu zámku obecně tak ano, hw spinlock je efektivnější než LLSC se zapnutou cache. V současném Linuxu tomu ale tak není a já se právě obávám, že to i nemusí být řešitelné vůbec (což ale nevím a tak jsem v jiné větvi nabídl těch 1kKč).

[little.owl]

Problém, že jaderné noviny se vyjadřují exkluzivně ke ticket spinlockům .

Primarni problem bylo cachovani a to je problem vsech spinlocku ve sdilene pameti.

[pc2005]

Pokračoval jsem v tématu Stena:

No jo, ale co uživatelé PCček? A taky je otázka, jak dobře jsou ty HW spinlocky implementované.

S tím, že chceš implementovat místo současnýho arch_spin_lock něco, co používá semafor pomocí IOMEM registrů.

Primarni problem bylo cachovani a to je problem vsech spinlocku ve sdilene pameti.

Ano, problém cachování vyřešíš buď tak, že dáš do necachovatelné oblasti semafor s pevně daným počtem použití. A nebo tak, že prostě u současného řešení vypneš cache. U prvního řešení musíš znova navrhnout křemík, u druhýho nemusíš někde dělat nic, protože to už hardware podporuje a když už musíš provést úpravu křemíku, tak z toho budou mít klidně zisk i jiné sekce kódu než implementace spinlocku.

[Michal Kubeček]

Podivná (byl to trochu offtopic, přiznávám) proto, že Linux defaultně neběží na x86-16 procesorech a na x86-32 se stejně musí udělat lock celého 64bit přenosu po sběrnici .

IMHO jde spíš o to, že spinlock_t se používá jako součást mnoha různých struktur, takže je praktické ušetřit trochu místa, pokud máme jádro přeložené tak, že 8+8 bitů stačí.

[pc2005]

Souhlasím napadá mě to jako jediná možnost (+ předpoklad, že nikdo nebude tak šílený a nedá na jednu páteřní sběrnici >256 x86 procesorů ). Problém je, že to IMHO podobný problém jako to s tou cache (granularita sběrnice/cache je větší a tak ta LOCK/cacheline operace s sebou vezme i okolní data).

[little.owl]

Jakmile ale člověk má podporu atomických operací po sběrnici, tak je jakýkoliv hw modul neefektivní zbytečnost.

Neni pravda v okamziku kdy musite kvuli tomu pristupovat do pomalejsi sdilene pameti pres X vrstev cache.

[pc2005]

Čistě teoreticky, když můžu dát nocache na pole IOMEM registrů, tak můžu udělat i stránku v RAM, do které umístí linker sekci se spinlock proměnnými. OMAP HW spinlock je také na sdílené sběrnici a data na něj musí jít přes MMU stejně jako u RAM.

HW spinlock na OMAP4430 je na interconnectu L4 (úroveň konfiguračních registrů periferií!). Zápis je prováděn s 32bit šířkou slova. Hlavní paměť je podle datasheetu zapojená na interconnectu L3 se dvěma přístupy (dva řadiče IMHO) a 128bit slovo. Taktovací frekvence L4 může být poloviční nebo stejná jako má L3. S tímhle fakt rychlý spinlock neuděláš, nicméně můžeš to zkusit. Dokonce pokud uděláš s OMAP hw spinlockem rychlejší implementaci arch_spin_lock, tak ti dám - řekněme litra .

P.S. Fakt si pořádně nedovedu představit, jak bys ty registry OMAP hw spinlocku používal. Napiš nějakej popis modelu. Zajímalo by mě to .

[little.owl]

Čistě teoreticky, když můžu dát nocache na pole IOMEM registrů, tak můžu udělat i stránku v RAM, do které umístí linker sekci se spinlock proměnnými. OMAP HW spinlock je také na sdílené sběrnici a data na něj musí jít přes MMU stejně jako u RAM.

Vy sice muzete naprogramovat MMU tak, ze blok pameti ktery obsahuje sdilena data mezi procesory neni cachovan. Musite tak naprogramovat vsechny MMU u vsech procesoru, nektere programovatelne periferie to neumoznuji a totalne zabijete vykon kvuli vzajemne memory arbitrazi, navic procesory maji ruzne pristupove priority na EMIF controlleru, takze zapomente na fair access, nehlede k tomu ze budete mit problemy s jejich ruznymi instrukcnimi sety.

HW spinlock na OMAP4430 je na interconnectu L4 (úroveň konfiguračních registrů periferií!). .... Dokonce pokud uděláš s OMAP hw spinlockem rychlejší implementaci arch_spin_lock, tak ti dám - řekněme litra .

Vy jste mozna kouknul zbezne do dokumentace, ale duvody proc TI implementoval HW spinlocky vam nedosly. Stale uvazujete v intencich jednoho OS bezicim na homogennim vicejadrovem procesoru. Jenze tady mame nekolik heterogennich procesoru s ruznymi instrukcnimi sety a architekturou, bezici na ruzne frekvenci, s nezavislymi i ruznymi operacnimi systemy, s programovatelnymi acceleratory a pak je HW implementace spinlocku jednoznacne nejlepsi reseni pro vzajemnou synchronizaci (spolu s HW mailboxy).

Jen litr !?!

jak bys ty registry OMAP hw spinlocku používal.

Jak to konkretne pouzivat mate v dokumentaci, myslim, ze i dokonce v te verejne dostupne.

[pc2005]

Já jsem nikdy nebyl proti použití hw spinlocku na heterogenních systémech pro komunikaci normálního CPU s třeba DSP. Na homogenních CPU s obecným Linuxem mě ale jejich použití přišlo neefektivní nebo nemožné. Je totiž rozdíl pokud ten hw spinlock použiješ jako vylepšení API pro komunikaci s DSP (to vítám, každý OSS driver je plus) nebo pokud se budeš ten hw spinlock snažit naroubovat na nejnižší úroveň spinlocků (a asi nejen jich) pro celý kernel.

Jen litr !?!

Ano jistě, v linuxové implementaci má arch_spin_lock jen 18 řádků a to počítám i definici funkce a oddělovací mezeru od arch_spin_trylock . Samozřejmě, že pro teoretickou implementaci s použitím hw spinlocku bys potřeboval třeba víc řádků, ale od nějaké délky by doba provádění kódu už byla míň efektivnější než současný stav. [joke] Kdybych nabídl mnohem víc než 1000Kč tak by hrozilo, že se touhou po odměně v tom návrhu zacyklíš a zblázníš se z toho . [/joke]

Vy sice muzete naprogramovat MMU tak, ze blok pameti ktery obsahuje sdilena data mezi procesory neni cachovan. Musite tak naprogramovat vsechny MMU u vsech procesoru

Pro přístup k registrům hw spinlocku musíš použít taky ioremap . Registry hw spinlocku budou mít možná výhodu tom, že IOMEM prostor se necachuje defaultně.

nehlede k tomu ze budete mit problemy s jejich ruznymi instrukcnimi sety.

Mno on bude hlavně problém v tom, že v linuxu budeš mít s heterogenní ISA problém jaksi obecně .

P.S. Začínám mít pocit, že v tom datasheetu používají TI jinou terminologii než Linux. To by pak možná vysvětlovalo tuto diskuzi.

[little.owl]

Já jsem nikdy nebyl proti použití hw spinlocku na heterogenních systémech pro komunikaci normálního CPU s třeba DSP.

Tim muzeme ukoncit diskuzi o OMAP HW spinclocich.

Na homogenních CPU s obecným Linuxem mě ale jejich použití přišlo neefektivní nebo nemožné.

Chybny zaver. Vzdy zalezi na jejich konkretni implementaci a jak jsou zadratovany do prislusnych jader. Realita je takova, ze dobre integrovany HW spinlock z podstaty strci do kapsy SW reseni ve sdilene pameti, jen se zatim jedna o pomerne specializovane procesory.

Pro přístup k registrům hw spinlocku musíš použít taky ioremap .

Zalezi na architekture, klidne si mohu vystacit s necim jako raw_readl/raw_writel, ci proste nejakymi custom asm makry; hlavni problem je pozadavek striktniho orderingu.

Začínám mít pocit, že v tom datasheetu používají TI jinou terminologii než Linux.

Tak TI dokumentace je znama tim, ze je casto bud neexistujici, neuplna, nespravna, tupe copy-paste-ovana nebo utajena a terminologie si lisi podle toho kde a kdo ji psal, zejmena Indiani jsou na mateni experti. Nicmene dokumentace OMAPu, kterou jste citoval je v podstate OK, jen chyby detaily a ty dostanete jako zakaznik od jejich supportu.

[pc2005]

Realita je takova, ze dobre integrovany HW spinlock z podstaty strci do kapsy SW reseni ve sdilene pameti, jen se zatim jedna o pomerne specializovane procesory.

Chybný předpoklad. Základ linux ticket spinlocku je vlastně taky takový "hw spinlock" (radši bych to ale pojmenoval jinak, ale v 3:29 už mě to fakt nemyslí), který ale dokáže obsloužit nekonečně mnoho klientů (prakticky omezeno na velikost RAM a počet procesorů). Dokonce má IMHO návrh ARMu prostředky jak vyřešit ty problémy s tou cache.

Zalezi na architekture, klidne si mohu vystacit s necim jako raw_readl/raw_writel, ci proste nejakymi custom asm makry

Stejně tak v NON_MMU Linuxu budou arch_spin_lock a spol. fungovat bez virtualizace paměti.

[little.owl]

Základ linux ticket spinlocku je vlastně taky takový "hw spinlock"

Neni. Je to SW thing se vsemi nectnostmi [a vyhodami].

Preji vam jednou neco implementovat na systemu s HW spinlocky a pak pochopite.

Konec.

[pc2005]

Jak říkám, mícháš jablka s hruškama. arch_spin_lock je softwarový ticket spinlock, jehož atomická část je implementovaná hardwarovým zámkem a instrukcemi LL-SC. Hardwarový zámek je implementovaný přímo v datové sběrnici a není tak vidět. Behem LL-SC, ale při přenosu adresy na počet procesorů jednomu z nich udělí zámek. V případě LL-SC bych dokonce řekl, že ten zámek je vlastně taky read-only neboť to čtení ti ten zámek získá. V linuxu (na rozdíl od DSP specializace) ti ale po tom LL může přijít vyjímka a tak by se ten zámek měl třeba během přerušení ztratit. Implementace toho zámku ve sběrnici je libovolná a tak tam může být klidně i zásobník 32+ adres (a nebo i jedný, jak je libo). Pointa je ale v tom, že řešení je transparentní - LL se nemusí starat o nějakou adresu iomem registru. Navíc může během toho čtení uložit nějakou hodnotu do RAM (pro implementaci třeba ticket spinlocku v linuxu - o kterém je zprávička).

Z dosavadní diskuze mám pak dojem, že prvotní implementace arch_spin_locku by z toho hw spinlocku dělala dokonce softwarový zámek, neboť by procesor musel nejdřív najít v tabulce, který registr mu přísluší (cache a TLB výpadek), pak přečíst iomem registr (TLB výpadek), modifikovat ticket (cache a TLB výpadek) a pak začít pracovat na datech. Kdežto standardní LLSC implementace je čtení adresy ticketu (cache a TLB výpadek), modifikace, zápis na stejnou adresu (pravděpodobnost cache nebo TLB výpadku je minimální, ale možná).

P.S. Tímto padá taky ta sázka o 1kKč, protože si to už dokážu představit bez příkladu .

[little.owl]

Jak říkám, mícháš jablka s hruškama. arch_spin_lock je softwarový ticket spinlock, jehož atomická část je implementovaná hardwarovým zámkem a instrukcemi LL-SC.

Jak funguji instrukce load-link / store-conditional je zrejme a pokud je to pro vas uz HW implementace spinlocku realizovana v ISA, budiz, pak vas postoj chapu. Nicmene true HW spinlocky jdu dale - zbavuji vas napriklad nutnosti neustale testovat stav ci diky queue zajistuji pricipielne fair access, a znovu o cache nemluve.

Kdežto standardní LLSC implementace je čtení adresy ticketu

U HW spincloku vam staci jen adresa jednoho registru.

Kdežto standardní LLSC implementace je čtení adresy ticketu (cache a TLB výpadek), modifikace, zápis na stejnou adresu (pravděpodobnost cache nebo TLB výpadku je minimální, ale možná).

Vzdyt prave tohle byl pro ne problem.

[pc2005]

Jak funguji instrukce load-link / store-conditional je zrejme a pokud je to pro vas uz HW implementace spinlocku realizovana v ISA, budiz, pak vas postoj chapu.

LLSC je instrukční vybavení, schopné využít libovolnou implementaci na sběrnici. Pokud ISA LLSC má, tak se dá celkem očekávat, že bude mít i tu implementaci na sběrnici. Implementace na sběrnici je potom ten hw semafor. Existence funkcí umožňujících atomickou read-modify-write operaci je napříč architekturami a je defacto standardní řešení.

zbavuji vas napriklad nutnosti neustale testovat stav

V linuxu se spinlocky velmi často používají v obsluze přerušení, kde je přerušení zakázáno a tudíž není výhoda mít tam interrupt notifikaci. U částí, kde by to šlo, bys musel implementovat obsluhu přerušení, ve které by zřejmě musel být taky spinlock a ten by už notifikaci přerušení IMHO používat nemohl. O něj by ale byla navíc největší soutěž.

a znovu o cache nemluve.

Jasně, použití hw spinlocku, kde zámek je mimo zamykaná data v systému, kde by naopak zámek měl být u dat je opravdu výhoda . Pokud přesunu současnou podobu mimo cacheovaný RAM segment anebo rezervuju doplněk do cacheline pro tento zámek, tak dostanu to samý, ale se softwarovou flexibilitou.

U HW spincloku vam staci jen adresa jednoho registru.

Linuxový proces může v jednu chvíli držet více než jeden ticket spinlock, což jedním registrem realizovat nelze . Nebo by se alternativně dalo říct, že LLSC nevyžaduje žádný registr a pracuje rovnou s daty .

Vzdyt prave tohle byl pro ne problem.

Pokud hw spinlockem realizuješ linux ticket spinlock (nebo mě neznámým způsobem ten spinlock upravíš tak, aby noarch funkce fungovaly na hwspinlocku a i na LLSC/CMPXCHG), tak budeš muset u hw spinlocku dělat mnohem víc čtení dat.

---

Jinak abych to shrnul, tak registrový hw spinlock je v pohodě, co se týče multijádra, kde je použití procesorů nerovnocenné (jeden procesor třeba dělá h264 dekodér nebo 3D softwarové vykreslování). Pro použití pro náhradu LLSC (například v linuxovém arch_spin_lock) je ale nevhodný. Pokud dokážeš dokázat opak (například implementací pro c6x kompatibilní s vanilla - když ti nepoužití hw spinlock tak vadí), tak jsem samozřejmě ochoten uznat, že jsem se mýlil.

[little.owl]

Pokud ISA LLSC má, tak se dá celkem očekávat, že bude mít i tu implementaci na sběrnici.

"dá celkem očekávat". Z takovych neopodstatnenych optimistickych ocekavanich jsem jiz vyrostl. Pouziti ldrex/strex na ARMu muze mit plno side efektu, zalezi na integraci jadra. Na dualcore Cortex M3 je jejich pouziti nad regionem s disablovanou cache pomale. Na dualcore Cortex-A9 MPC s SCU a ACP nam vznikaji nahodne delay, kdy jedno jadro lock uvolni a druhe jadro ho stale vidi uzamknute a stezovat si muzete tak na Hlavnim nadrazi. MIPS od Broadcomu s ll/sc na tom neni o tolik lepe.

Pokud přesunu současnou podobu mimo cacheovaný RAM segment anebo rezervuju doplněk do cacheline pro tento zámek, tak dostanu to samý, ale se softwarovou flexibilitou.

Vyplnovani cache balastem - "doplnek" - je cesta vpred? To se vrati jak bumerang, minimalne pres cache utilization a rozhodne to neni "to same".

tak registrový hw spinlock je v pohodě, co se týče multijádra, kde je použití procesorů nerovnocenné (jeden procesor třeba dělá h264 dekodér nebo 3D softwarové vykreslování).

Mapovani aplikace na jadra je irelevantni, to se muze menit klidne v case a za chodu. Dulezity je jen objem sdilenych dat ktere je treba synchronizovat, snaha omezit lock overhead, lock contention ci starving a v cele rade scenaru muze byt HW synchronizace proste lepsi volba.

Pro použití pro náhradu LLSC (například v linuxovém arch_spin_lock) je ale nevhodný.

Nejde o LLSC ci CAS, instrukcni balast okolo je znacny, ted budou tunit jestli 50 nebo 2.7, experimentovat, ale podstatu problemu, cache miss, stejne nevyresili, trochu to omezili, zvysili komplexitu kodu a zhorsili chovani pro kratke doby lockovani. Zmeny ve spinlocich v kernelu jsou never-ending story, takze pockejme na dalsi dil.

[pc2005]

"dá celkem očekávat". Z takovych neopodstatnenych optimistickych ocekavanich jsem jiz vyrostl.

Pokud nebude mít funkční implementaci LLSC, tak nepůjde udělat víc než jen ticket spinlock. Veškeré atomické operace tím pak půjdou do pryč a ani SMP podpora nebude možná. Počet atomických operací navíc na rozdíl od spinlocků nemá žádné omezení.

Stejně tak se dá očekávat, že registrový hw spinlock nebude na většině architektur obsažen vůbec.

kdy jedno jadro lock uvolni a druhe jadro ho stale vidi uzamknute

Tato situace je validní. Stěžuje pouze návrh realtime systému, kde se počítá s dobou trvání na úrovni jednotlivých instrukcí.

Vyplnovani cache balastem - "doplnek" - je cesta vpred? To se vrati jak bumerang, minimalne pres cache utilization a rozhodne to neni "to same".

Tohle byla ukázková implementace jak na fungujícím (možná pomalém) ticket spinlocku vyřešit soutěžení o cacheline. Možná naivní, ale efektivnější (~rychleji navrhnutý model) než registrový hw spinlock. No je fakt, že ten nápad se prostě nabízel (a je dokonce možnost, že jsem ho periferním viděním v nějakém článku nebo diskuzi zahlédl a podvědomě použil jako optimalizaci vymýšlení řešení), ty jsi ale ani po opakovaných nabídkách nezveřejnil možný model (nakonec jsem vymyslel částečnou a skoro nerealizovatelnou kostru já).

Pro cacheline o velikosti 64B: časem bude IMHO šířka ticketu 64bitová, protože instrukce používající 32bit budou pomalejší, s delším opkódem nebo nebudou vůbec. Do zbytku pole by šly uložit ty hodnoty kalibrace proporčních prodlev (využívány stejně jen jádry co zrovna soupeří). To je hnedle čtvrtina cacheline zaplněná. Hlavně jde o to, že RAM is cheap (a dovolil bych si tvrdit, že i SRAM, použitá na cache). Hlavně ale je transparentní, což se o registrech, kterých je defaultně málo a bude se asi přidávat časem (jakpak že Intel přidával x86 instrukce?), říct nedá.

Pokud by se mým návrhem odstranily problémy s přetahováním cacheline, tak bude přístup k L1 mnohem rychlejší než zápis na L4 registr (sám jsi to psal).

Mapovani aplikace na jadra je irelevantni, to se muze menit klidne v case a za chodu.

A jak s registrovým hw spinlockem s 32 zámky vyřešíš to, že objem aktuálně držených zámků (od všech spuštěných aplikací) je třeba 33?

cele rade scenaru muze byt HW synchronizace proste lepsi volba

Však píšu, ale pro vanilla linux ticket spinlock (o kterém je zprávička) prostě ne.

instrukcni balast okolo je znacny, ted budou tunit jestli 50 nebo 2.7, experimentovat

Nebudou, euler pro x86 a 42 pro ARM . Se musím podívat, zda taky někoho nenapadlo to vyplnění struct arch_spinlock_t na velikost cacheline (není možný, aby to fakt napadlo jen mě ).

takze pockejme na dalsi dil

Asi jo, protože bez implementace registrového hw spinlocku v linuxu, mě to o jeho větší efektivnosti fakt nepřesvědčí. Škoda, že kámoš nemá pandaboard, ale jen beagleboard .

[little.owl]

Pokud nebude mít funkční implementaci LLSC, tak nepůjde udělat víc než jen ticket spinlock.

To je situace soucasneho ARMu, jejich cely support pro vice jader neni nejspolehlivejsi a je treba se vyvarovat rizikovym scenarum. Pred nekolika lety LLSC nahodne selhavalo, problem se objevovat na procesorech Freescale a TI, a tak bylo zrejme, ze chyba je v designu ARMu. Nakonec se to podarilo spolehlive reprodukovat a ARM byl nucen uznat chybu v integraci SCU. A jeho reseni? Pridal do manualu nasledujici note, castecne off topic:

Note

This might occasionally lead to false negatives, or delays caused by transferring data between caches when several processors attempt to access synchronization variables within the same ERG block at the same time. For performance reasons, it might be worth to explicitly place very frequently accessed synchronization variables at least the size of the ERG apart in memory.

TI a Freescale se to pokusili opravit, procesory s takovymi problemy byly obtizne prodejne, a u TI dopady jejich fixu jsou prave treba ony masivni nahodne delays.

Tato situace je validní. Stěžuje pouze návrh realtime systému, kde se počítá s dobou trvání na úrovni jednotlivých instrukcí.

Coz je problem, u aplikace to muze vest ke ztrate packetu, potazno video framu. Oni totiz veci, ktere by nemely trvat vice nez 200 hodinovych cyklu mohou trvat klidne 20 000 cyklu. Tech veci, ktere jsou nespolehlive je vice. Pokud je blok pameti namapovan v MMU jako shareable a v dane oblasti se provede DMA transfer, ARM exclusive monitor selhava - a informace z nej se pouziva v LLSC, pak selhavaji semafory. Odpoved TI - udelejte synchronizaci jinak. Faktem proste je, ze HW spinlocky a HW mailboxy funguji naprosto spolehlive, nikdy s nimi nebyl problem.

tak nepůjde udělat víc než jen ticket spinlock.

Co porad s tim ticket spinlockem mate? Neni to panacea. Krome zlepseni fair access na nem nic neni.

Stejně tak se dá očekávat, že registrový hw spinlock nebude na většině architektur obsažen vůbec.

Bohuzel.

A jak s registrovým hw spinlockem s 32 zámky vyřešíš to, že objem aktuálně držených zámků (od všech spuštěných aplikací) je třeba 33?

To je vzdy problem omezenych zdroju, musite se s tim vyporadat, casto je to kompromis a prave proto se pouziva dynamicka [re]alokace za chodu. Pokud je to blocker a potrebuji jich vice, pouziji jiny procesor.

Však píšu, ale pro vanilla linux ticket spinlock (o kterém je zprávička) prostě ne.

Tyhle veci ziji vetsinou ve vlastnich vetvich vyrobcu CPU a pokud neotravi Linuse, do vanila se to nedostane. Je to vetsinou neportovatelny bordel, nicmene ne pro to, ze by to napsat slusne neslo.

zda taky někoho nenapadlo to vyplnění struct arch_spinlock_t na velikost cacheline (není možný, aby to fakt napadlo jen mě ).

Nepouzivaji to. Nenapadlo to jen vas, zarovnavani objektu na size cache line se pouziva, ale cena za to je vysoka. Problem je v tom, ze to neresi problem, ale jen omezuje side effects.

[pc2005]

To je situace soucasneho ARMu, jejich cely support pro vice jader neni nejspolehlivejsi a je treba se vyvarovat rizikovym scenarum. Pred nekolika lety LLSC nahodne selhavalo, problem se objevovat na procesorech Freescale a TI, a tak bylo zrejme, ze chyba je v designu ARMu. Nakonec se to podarilo spolehlive reprodukovat a ARM byl nucen uznat chybu v integraci SCU. A jeho reseni? Pridal do manualu nasledujici note, castecne off topic:

A proč by mělo být lepší místo snahy o opravení zjevného bugu ten bug workaroundovat špatně škalovatelnou periferií. Při vhodné implementaci by mohl LLSC arbitr reagovat stejně jako hw spinlock. Řekl bych, že i ty budící interrupty by šly.

Co porad s tim ticket spinlockem mate? Neni to panacea. Krome zlepseni fair access na nem nic neni.

Tady jde o to, že současná implementace je v linuxu provázaná mezi různými drivery, společnými kódy a dokonce i architekturami. Jakákoliv změna implementace zámků by musela být udělaná kompatibilně pro všechny zdrojáky v linuxovém jádru. Tedy pokud bys chtěl nahradit současné řešení zámků (třeba ten ticket) něčím na jiném principu, tak bys to musel udělat kompatibilně se zbytkem kernelu a nebo zbytek kernelu upravit na novou metodu. IMHO Linus takový mega změny moc rád nemá (a podle mě dělá dobře). Už jen vlastně taková trivialita jako změna printk(KERN_INFO...) na pr_info(...) je problém řešitelný přes sed a stále nacházím v kódu printk výpisy (mám tušení, že proti tomu sedu byl Linus taky).

Z těchto důvodů by byla implementace registrového spinlocku náročná (i když na kód asi ne, jen to okolo a prosazení do vanilla) a proto to není tak efektivní.

To je vzdy problem omezenych zdroju, musite se s tim vyporadat, casto je to kompromis a prave proto se pouziva dynamicka [re]alokace za chodu. Pokud je to blocker a potrebuji jich vice, pouziji jiny procesor.

Ovšem ta alokace stojí čas (taky bych řekl, že ten alokátor musí mít také vyřešenou arbitráž přístupů). Pokud tím jiným procesorem myslíš jako jiný model čipu, tak to řeší jen do dalšího nárustu a funguje to jen u jednoúčelového/průmyslového zařízení. Uživatelům osobního počítače by se asi nelíbilo, kdyby si museli s dalším programem shánět novej procesor .

Tyhle veci ziji vetsinou ve vlastnich vetvich vyrobcu CPU a pokud neotravi Linuse, do vanila se to nedostane. Je to vetsinou neportovatelny bordel, nicmene ne pro to, ze by to napsat slusne neslo.

Taky bych řekl, ale na linuxovém stroji by právě měl být jen ten portovatelný (bordel ).

Nepouzivaji to. Nenapadlo to jen vas, zarovnavani objektu na size cache line se pouziva, ale cena za to je vysoka. Problem je v tom, ze to neresi problem, ale jen omezuje side effects.

Já vím, sám si s tím budu asi brzo hrát. Lze tím optimalizovat program. Koneckonců datové struktury se na kompech zarovnávají (a vyplňují) i obecně. Takovej stack je (i když nemusí) zarovnaný na stránku. Klasické je zarovnávání na šířku sběrnice apod. Takže bych řekl, že zarovnání spinlocku na cacheline zas tak hrozný nebude (minimálně ne na vanilla linuxu).

[little.owl]

A proč by mělo být lepší místo snahy o opravení zjevného bugu ten bug workaroundovat špatně škalovatelnou periferií.

Nerikam, ze je to lepsi a urcite by bylo od vyrobcu moc hezke pokud by vychytali vsechny HW race conditions. Pokud nic lepsiho nemam, musim hledat cesty jak s tim pracovat, to je rozdil mezi "teoreticky" a "prakticky". Ted, pokud chci neco spolehliveho, sahnu na nejaky derivat skoro ctyricet let stareho designu Motoroly 6800, tupy procesor, ale spolehlive fungujici.

[pc2005]

Jj taková platforma s vychytanýma bugama by byla skvělá.

Pokud nic lepsiho nemam, musim hledat cesty jak s tim pracovat, to je rozdil mezi "teoreticky" a "prakticky".

No je tu ještě jedna cesta a to navrhnout si takový hardware sám .

[little.owl]

Pocet spinlocku je limitovan, TI HW jich ma 64, ale mohou byt dynamicky alokovany na urovni driveru. Hlavni kouzlo spociva v tom, ze jsou zadratovany s procesory a jejich uziti je rizeno asynchronnimi HW interrupty, tudiz si usetrite checkovani nejake sdilene pameti pres X cache.

[pc2005]

Nemůžu si pomoct, ale mě se to řešení pro obecné spinlock použití nelíbí . Pro komunikaci DSP ←→ ARM to je jiná, tam je to v pohodě. Mezi ARM a ARM je ale mnohem lepší způsob.

Důvody:

• V datasheetu OMAP4430 je jich jen 32. Driverů klidně může být 32+ a s aktivním čekáním na spinlock.
• "Not support any interrupt (normální spinlocky podporují)"
• "ale mohou byt dynamicky alokovany na urovni driveru." - to IMHO není správné použití, navíc, co když se sejde víc procesorů a bude žádat ten samý spinlock
• V jaderných novinách je popisovaný ticketspinlock, který obsahuje prakticky čítač čekajících a vyřízených požadavků (je to přímo realizovaný pro konkurentní čekání). OMAP spinlock je spíš semafor.
• Co tu cache vypnout? OMAPy maj na čipu přímo SRAM. Pokud by byla rychlejší než RAM, tak by cache nepotřebovala a spinlocky by se mohly ukládat do ní. I kdyby nebyla stejně rychlá jako CPU, tak oni ty hw spinlock registry taky asi nebudou mít frekvenci procesoru.

[little.owl]

To co jste predvedl je typicka analyza cloveka, ktery sklada informace z utrzku webu a pak z toho dela zavery, aniz by si na to nekdy prakticky hrabnul a mel k tomu relevantni informace.

TI procesory jsou stavebnice a oni stejne jako dalsi vyrobci, siji procesory na miru svym velkym zakaznikum. Procesory, ktere pouzivame my, jsou usite na zakazku pro konkretni uziti pri zpracovani videa v automotive segmentu, v soucasnosti TI nabizi 128 spinlocku, brzy to bude asi bezne u i komerne dodavanych cipu.

Alokace na bazi driveru - mezi aplikaci a vlastnim HW je vrstva driveru/frameworku, TI jich dodava svym zakaznikum nekolik, vcetne verzi do SYS BIOSu a reseni v linuxovem kernelu s citacem je jen dalsi framework v rade postaveny nad konkretnim HW s vlastnim API.

to IMHO není správné použití, navíc, co když se sejde víc procesorů a bude žádat ten samý spinlock

Tohle je spravny pristup, pokud chcete dynamicky sdilet omezene HW resources v case.

Pokud by byla rychlejší než RAM, tak by cache nepotřebovala a spinlocky by se mohly ukládat do ní.

Ona je rychlejsi nez RAM, ale stale vyrazne pomalejsi nez L1, navic u heterogennich procesoru vam kazde jadro a periferie bezi na ruzne rychlosti. A opet je tu cache a sirka cache line. Vam vubec nedosla vyhoda, ktera je ostatne viditelna i z kodu linuxoveho frameworku - vlastni HW pracuje s bitovymi zapisy do registru provadenymi fakticky bez cekani, a lockovani je provedeno uzitim jednoduche read-access operace, bez nutnosti read- modify-write operaci, coz (a) nektery HW nezvlada, (b) je pomale tak jako tak, neb to vyzaduje vice prenosu na vnitrnich zbernicich. K interruptum - pokud cekate v prumeru mene nez 200 cpu cyklu, je reseni pomoci nich naprosto nevhodne a pomale, vyjimkou jsou programovatelne periferie jako HDVPSS/HDVICP (ktere jdou totalne mimo Linux), kde se to resi pres spinlock interrupty integrovane v PRCM - pak se to skutecne podoba vice velmi efektivnim semaforum - jenze u veci jako HDVICP jsou problemy s cache a pripadne dopady na vykon systemu nejvetsi.

[pc2005]

No konečně jsme se k tomu dostali . Na to se náznakama ptám už od začátku vlákna.

Je sice hezké, že ten hw spinlock je read-only operace, samotná ale nemůže linux spinlock nahradit. A to proto, že linux spinlock není jen read-modify-write operace. Navíc ten problém s cache je v tom, že ostatní právě ten read-only provádějí. Tenhle problém ten hwspinlock řeší nevědomky tím, že je v jiné sekci adresovatelného rozsahu. Linux spinlock lze ale lehko na tenhle stav upravit už jen tím, že se vypne cache. Nebo snad dokonce jen tím, že ticket bude dál od upravovaných dat (sám v cacheline). Tou redukcí do hw spinlocku ale:

a) Ztratíš ten neomezený počet, který máš když použiješ linked read/write instrukce

b) Pokud je to vůbec možné, tak budeš muset pro každý linux spinlock udělat wrapper, co dynamicky používá ty hw spinlock registry.

c) Budeš muset rozdělit implementaci arch_spin_lock pro jeden arch/arm a pro druhej arch/arm. V drtivé většině ostatních architektur se to bude ale řešit klasicky pomocí LLSC/cmpxchg/apod.

Ona je rychlejsi nez RAM, ale stale vyrazne pomalejsi nez L1

Ale (SRAM) je stále rychlejší než L4, kde je hw spinlock .

To co jste predvedl je typicka analyza cloveka, ktery sklada informace z utrzku webu a pak z toho dela zavery, aniz by si na to nekdy prakticky hrabnul a mel k tomu relevantni informace.

No přiznávám, že jsem si nekrokovat ten přechodový graf z OMAP datasheetu na papír neboť bylo po 4AM (stejně jako teďka kdy už víc než půl hodiny píšu tohle ). Na první pohled jsem ale viděl, že by náhrada linux ticket spinlocku byla neefektivní a možná i nemožná a tak byly ostatní informace irelevantní a dál jsem nepokračoval. Ale chápu, že jsem mohl udělat chybu v úsudku a/nebo napsat nesrozumitelný text (to bude i teďka: 5:35... ).

K interruptum

Interrupty jsou irelevantní, linux spinlocky (ta nejnižší část) podporují preempci i interrupt disabled.

P.S. Ještě alternativně: HW spinlocky jsou neefektivní, protože je to nový hw a je jednodušší prostě upravit arbitr pro LLSC (které jsou už v ISA specifikaci), aby jinak řešil cache, než zavádět nový hw, který má omezenou kapacitu.

[little.owl]

Uz me to nebavy, stale dokola. Znovu a naposledy. OMAP nelze provozovat tak, ze na A8, DSP a dalsich jadrech mate jednu instanci Linuxu a ty v ramci jednoho beziciho kernelu synchronizujete. Pokud se nedokazete odpoutat od tohoto scenare, bude vam tato konkretni HW implemantace spinlocku vzdycky pripadat neefektivni. Pokud se na to budu divat optikou kernelu beziciho pouze a jenom na A8, nema smysl spinlocky zalozene na HW modulu v teto konkretni implementaci skutecne pouzivat. Ale v okamziku, kdy budete chtit sesynchronizovat A8 s Linuxem a DSP se SYS BIOSem, zjistite, ze nemate lepsi reseni a pokud zvolite jine reseni, treba pres sdilenou pamet, vyzerete si prave problemy cachovanim (a mnoho dalsich) plnymi dousky. Uziti SRAM problem neresi a ani pres vyssi rychlost primarniho interkonektu to rychlejsi nebude.

K dynamicke alokaci. Jadra a acceleratory se pouzivaji k urcitym scenarum, ktere se v case mohou menit. Ja treba na Netre menil bezici algoritmy zpracovavajici video a kazdy algoritmus potreboval synchronizovat jine datove struktury. Pri prepnuti jader do modu s jinym algoritmem, se pouzite spinlocky dynamicky rekonfiguruji, za chodu algoritmu se to jiz nemeni, handshake mezi jadry je pomaly. Jejich pocet me nikdy v praxi netlacil.

Interrupty. Opet vam nedoslo, co jsem rikal. Ja nikdy nemluvil maskovani interruptu v ramci uziti spinlocku ci jejich uziti v ISR. Jde o to, ze u nekterych HW implementacich muze byt procesor pokousejici se ziskat spinlock notifikovan HW interruptem v okamziku, kdy je spinlock k dispozici a nemusi tak cyklicky ve smycce testovat stav spinlocku. V Linuxu to podporuje driver HW spinlocku u Tegry (tam je to spise semafor), u OMAP to stale chyby - ne vsechen TI HW to podporuje.

[pc2005]

OMAP nelze provozovat tak, ze na A8, DSP a dalsich jadrech mate jednu instanci Linuxu a ty v ramci jednoho beziciho kernelu synchronizujete.

A právě proto nelze hw spinlockem nahradit linux ticket spinlock.

Jiné použití neřeším, ale v takovém případě s ním souhlasím (ale myslel jsem, že tohle je jasné).

u OMAP to stale chyby - ne vsechen TI HW to podporuje

A proto by bylo neefektivní řešení ho cpát na PC pro arch_spin_lock.

[little.owl]

A proto by bylo neefektivní řešení ho cpát na PC pro arch_spin_lock.

Ne. Problem jsou priority, za dva roky se to nikam v Linuxu nehnulo a pritom jsou si moznosti vedomi - viz. treba zminka u C6474 zde. Nic z toho jeste neni a pricemz treba HW support pro queuing jader u spinlocku je vyborna vec.

[pc2005]

Ale pořád to je jen pro použití na komunikaci s pomocným procesorem jako je třeba DSP nebo pomocný kontrolér. Kde často ani neběží jina instance Linuxu, ale jen standalone kód. U univerzálního programu (který je třeba spochen online spouštět předem neznámé úlohy) to použít lze jen s velkými obtížemi.

[little.owl]

Ale pořád to je jen pro použití na komunikaci s pomocným procesorem jako je třeba DSP nebo pomocný kontrolér.

Neni. C6474 je homogenni vicejadrovy procesor, zadny OMAP.

[pc2005]

The C6474, a multi-core DSP device, have Linux running on one of its cores

Platforma homogenní možná je, použití nikoliv. Z pohledu současnýho linuxu to tedy bude uniprocessor komunikující s x DSP procesory a použije se framework pro semafory na DSP. Nebo to bude x uniprocesorů komunikujících s ostatními přes mailboxy, ale to je už jiné řešení, něco jako NUMA-cc až cluster, kde si jednotlivé stanice nemusí vidět do RAM. S implementací arch_spin_lock na tom jednom node pomocí registrového spinlocku budeš mít problém stále.

Alt: Můžeš na tom C6474 udělat kernel se standardním API, aby vlákna libovolné vícevláknová aplikace mohly běžet na více jádrech zároveň?

P.S. Podpora c6x v linuxu mě stále přijde jako betaverze (donedávna ve vanilla nebyla). Ono je dost obtížné udělat podporu v obecném operačním systému na architektuře, která je určena IMHO na statickou optimalizaci knihoven pro věci jako FFT a jiné DSP aplikace. Ono se stačí podívat třeba na obsah entry.S a člověku se z toho motá hlava . Nicméně podle zběžného průzkumu instrukční sada C64x obsahuje instrukci CMTL. Pokud existují modely, co tuhle instrukci zrovna nepodporují, tak smolík, ale ke sdíleným datům o libovolném dynamickém počtu prostě jednoduše v Linuxu nemůžou.

[little.owl]

Můžeš na tom C6474 udělat kernel se standardním API, aby vlákna libovolné vícevláknová aplikace mohly běžet na více jádrech zároveň?

Ano, prostredky na to jsou, jen to [zatim] nedotahli do konce, vyvoj vypada mrtve.

[Kvakor]

2,7? Vůbec bych se nedivil, kdyby to bylo jen zaokrouhlené Eulerovo číslo 2,7182818284...

[dumblob]

+1

[Vladimír Čunát]

To mě přesně taky napadlo. V podobných kontextech vychází e jako optimum docela často.

Mimochodem, žil jsem v domění že je dnes standardní velikost cache-line 64B... a u mého CPU rozhodně ano. Ostatně, každý si může zkontrolovat cestu někde okolo /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size

[kralyk z abclinuxu]

+1, to mě přesně taky napadlo

[jk001]

díky za prima článek :)