Škálování výkonu v dual-socket systému

RDa

  • *****
  • 2 681
    • Zobrazit profil
    • E-mail
Škálování výkonu v dual-socket systému
« kdy: 30. 04. 2023, 13:56:29 »
Ahoj, nějakou dobu testuji hromadu sestav se stejnou zátěží (kompilace kernelu v ramdisku) a měřím čas a idle/load spotřebu.

Na sestavách, které mají dva sockety dostávám při 2 CPU podprůměrný - handicapovaný výkon, např.

Kód: [Vybrat]
1S 1xE5-2603 v3 (4x8GB ram) ... 17m55s
2S 2xE5-2603 v3 (8x8GB ram) ... 10m01s

Očekávaný ideální stav by byl spíše 8m58s, teď je 2S o cca 11% pomalejší.

Tuším, že problém bude někde v NUMA - jakože část té hromady (make -j13 pro 2x 6C/6T) gcc instancí má alokace paměti z druhého socketu, ke kterému vede celkem úzké spojení a s velkými latencemi.

Jak lze tohle řešit na obecné úloze (kernel make) ?
Na custom aplikaci by asi šlo přidat hinty ohledně alokace paměti, ale zde fakt nevím.



Re:Škálování výkonu v dual-socket systému
« Odpověď #1 kdy: 01. 05. 2023, 21:36:22 »
Mne to pride vpohode (tych 10% dole).

Otazka je, ci by podobny pokles vo vykone nebol i vtedy, keby si ma ekvivalentny CPU s 12jadrami (s jednym NUMA nodom). Mozno to s NUMA nema nic, teda isto to ma nejaky vplyv, ale nejaky "automatic kernel numa balacing" v novym modernych jadrach, by tie alokacie pamate mal snad riesit automaticky.

jjrsk

  • ****
  • 490
    • Zobrazit profil
Re:Škálování výkonu v dual-socket systému
« Odpověď #2 kdy: 02. 05. 2023, 08:35:31 »
I kdyz budes testovat jeden CPU a navysovat jeho jadra, bude ti klesat ziskany vykon per dalsi jadro. Jak moc zalezi na aplikaci, ale pokles nameris vzdy.

Vzdy pak dojdes k nejakemu cislu, kdy naopak pridanim jadra klesne i celkovy vykon. Jednoduse proto, ze na obsluhu kazdeho dalsiho potrebujes nejaky dalsi vykon.

Vice jader vs vice procesoru taky zalezi na appce - jadra muzou tezit z rychlejsiho pristupu do cache, cpu zase z paralelizovatelneho pristupu do ram (zalezi pochopitelne i na HW a tom jak je to udelane).

dr_ak

Re:Škálování výkonu v dual-socket systému
« Odpověď #3 kdy: 02. 05. 2023, 11:24:28 »
Myslím, že kompilaci kernelu nelze ideálně (lineárně) škálovat.
Jsou tam závislosti, na které se čeká, některé operace se neškálují, atd...
Tak na otestování dual-socketu bych použil jinou vhodnější zátěž.

alex6bbc

  • *****
  • 1 639
    • Zobrazit profil
    • E-mail
Re:Škálování výkonu v dual-socket systému
« Odpověď #4 kdy: 02. 05. 2023, 11:41:39 »
kernel jsem si nebuildil uz roky, ale neda se sestaveni modulu spustit samostatnym parametrem (make modules), coz by mohlo vytezit dalsi cpu a jadra?


Re:Škálování výkonu v dual-socket systému
« Odpověď #5 kdy: 04. 05. 2023, 09:34:33 »
Myslím, že kompilaci kernelu nelze ideálně (lineárně) škálovat.
Jsou tam závislosti, na které se čeká, některé operace se neškálují, atd...
Podle mých zkušeností naopak build jádra škáluje při běžném počtu CPU (nižší desítky) velmi dobře, pokud (1) je konfigurace dostatečně bohatá (třeba allmodconfig nebo distribuční jádra), (2) je dost paměti a (3) úzkým hrdlem je opravdu CPU, ne třeba disk (tj. překlad např. na tmpfs). Je potřeba si uvědomit, že většinu času se překládají jednotlivé soubory, které na sobě nezávisejí; v podstatě jediná část, která škáluje opravdu špatně, je linker (a i to se snad v dohledné době změní).

RDa

  • *****
  • 2 681
    • Zobrazit profil
    • E-mail
Re:Škálování výkonu v dual-socket systému
« Odpověď #6 kdy: 04. 05. 2023, 12:59:32 »
Myslím, že kompilaci kernelu nelze ideálně (lineárně) škálovat.
Jsou tam závislosti, na které se čeká, některé operace se neškálují, atd...
Podle mých zkušeností naopak build jádra škáluje při běžném počtu CPU (nižší desítky) velmi dobře, pokud (1) je konfigurace dostatečně bohatá (třeba allmodconfig nebo distribuční jádra), (2) je dost paměti a (3) úzkým hrdlem je opravdu CPU, ne třeba disk (tj. překlad např. na tmpfs). Je potřeba si uvědomit, že většinu času se překládají jednotlivé soubory, které na sobě nezávisejí; v podstatě jediná část, která škáluje opravdu špatně, je linker (a i to se snad v dohledné době změní).

Presne tak. Ta konfigurace sice neni allconfig, ale mam zapnuto hodne modulu pro pripad co by kdyby jedou bylo treba a je to cca 2x delsi kompilace nez kdybych udelal jadro na miru konfigurace jednoho stroje.

Temer cela kompilace je vicevlaknova, jsou tam nizsi jednotky vterin nez se rozhodne o kompilacnim poradi na pocatku, a pak vyssi jednotky vterin se stravi jednovlaknove na linkeru a kompresi vysledneho jadra. Cele to bezi vzdy z cerstve rozbalene testovaci sady do /dev/shm.

Extremni vysledky z me testovaci sady stroju jsou 1m14s (Epyc Rome 7702P 64C/128T) vs 1h:57m09s (Celeron N3050 2C/2T). Pod 5 minut to da moderni highend, pod 10 minut to da bezna desktop sestava. Cokoliv nad 15-30min je z dnesniho pohledu spis pomalej komp.

Samozrjeme absolutni cas nebylo to co me zajimalo, ale efektivita - takze mam i data o idle/load spotrebe a nektere stare systemy celkem prekvapily - pokud se to ma vzit nejakym TCO vzorcem, tak porad existuji optimalni reseni (pro ruzne potreby to vychazi ruzne). Plus je zajimave videt, ze kdyz se operacni bod posune mimo boost/turbo, tak o kolik lepsi je dane reseni.

CPU

  • *****
  • 833
    • Zobrazit profil
    • E-mail
Re:Škálování výkonu v dual-socket systému
« Odpověď #7 kdy: 04. 05. 2023, 13:47:43 »
Předně "Kde jsou ty prachy Lebowski!" resp. v tomhle případě "Kde jsou ta data Lebowski!".
Ideální zátěž běží tak, že má DATA u PROCESORU.

N+1 stupeň neideální zátěže
Proces běží na procesoru B, ale data jsou v paměti procesoru A.

N+2 stupeň neideální zátěže
Proces běží na procesoru B, ale data jsou v paměti procesoru A a navíc procesor A paměť intenzivně využívá.

N+3 stupeň neideální zátěže
Proces běží na procesoru B, ale data jsou v paměti procesoru A a navíc jsou data sdílená, jsou tam možné semafory a locky, tedy se čeká na uvolnění semaforu.

N+N+1 stupeň neideální zátěže
Procesy běží na procesoru B, ale data jsou v paměti procesoru A a všechny tyto procesy se naráz různě zkouší dostat k těmto datům.

...penalizace 10% je v podstatě důkaz toho, že to je dobře udělané.

Problematika přidělování paměti procesům je sama o sobě zajímavá.
Původní strategie byla taková, že jak se paměť plnila, zabíraly se jednotlivé paměťové banky.
Tj. nejprve se kompletně naplnila paměť u procesoru A, pak se teprve začala zabírat paměť u procesoru B.
Teď je to myslím tak, že se data dávají do paměti "mateřského procesoru", tedy tam, kde se paměť poprvé naalokovala.
Pokud spouštíš samostatné procesy, bude distribuce zřejmě ideální, ale pokud pouštíš jeden proces a ten proces si alokuje paměť, měla by data být primárně přístupná z domény daného hlavního procesu a tedy na tom procesoru s tím, že plánovač by neměl stěhovat vlákna na další CPU, dokud se mu to bude zdát OK.
Jaký je aktuální stav na linuxu nevím (!!!).
« Poslední změna: 04. 05. 2023, 13:52:49 od CPU »

RDa

  • *****
  • 2 681
    • Zobrazit profil
    • E-mail
Re:Škálování výkonu v dual-socket systému
« Odpověď #8 kdy: 04. 05. 2023, 18:56:10 »
...penalizace 10% je v podstatě důkaz toho, že to je dobře udělané.

No jo.. mohlo by byt i hur :-)

Co jsem studoval ty novsy EPYCy, tak tam je to reseno ve vice rovinach:

 - kazdy kvadrant ma nejblize 2 pametove kanaly, ostatni jsou skrze IF trocha vzdalenejsi

 - jsou nizkojadrove procesory, ktere maji vsechna jadra jen v podmnozine CCD, takze zde je dobre osazovat patricne kvadranty (vyzkouseno, rozdil mezi spravne osazenymi sloty a nespravne osazenymi je vice nez znatelny!) - bylo stesti ze ty cpu maj poruchu zrovna na tom kanalu, ktery neni potreba k optimalni funkci :-)

 - nejlepsi je mit osazeno pameti vyvazeno a zapnout NPS4 (4 numa nodes), takze OS vi o tech kvadrantech ktere seskupuji procesory a pameti

 - horsi volba je NPS2 (rozdeleni na pulky)

 - a pak asi nejhorsi strategie prezentace pameti je takova, ze veskera pamet je jeden velky pool a pak se provadi memory interleaving nekde kolem 8 nebo 9 bitu (bios nastaveni) - tj. pri 8 bitech by se melo jednat o to, ze souvislych 256 bajtu je v jedne dimm, dalich 256 bajtu ve vedlejsi dimm a tak dokolecka dle poctu kanalu. Tohle rozhazuje data stejnym dilem do pameti, ale taky znamena casto velke latence.

Re:Škálování výkonu v dual-socket systému
« Odpověď #9 kdy: 04. 05. 2023, 22:00:47 »
Zkus vypnout spectre a meltdown optimalizace a otestuj znovu.

Jinak mimochodem si myslim ze ikdyby se ty jadra z 2. cpu nastehovala do toho 1. tak by vykon linearne nahoru nesel z duvodu ruznych delek zpracovani jednotlivych podprocesu a podprocesy nove v nekterych situacich musi na dokonceni podprocesu starych cekat.

Srovnej se zpracovanim audia nebo grafiky, kdy kazdy podprocess si muze vzit urcitou cast dat na zpracovani a nemusi vedet co dejali ostatni podprocesy na techto datech pracujicich. Samozrejme ze se to lisi od kodeku nebo filtru.