Navržené systémové volání umožní aplikacím vybírat si procesorová jádra

Nejsem nizkourovnovy programator, takze si dokazi tezko predstavit k cemu je to dobre, ale za moznost vyberu cehokoliv jsem vzdy rad. Nicmene u tohoto me zarazi jedna vec. Neni to bezpecnostni riziko? Mame tu zranitelnosti procesoru a minimalne v jednom se resilo ze skodlivy SW musi bezet na stejnem jadre(na jinem threadu) a pak lze bud odposlechnout datovy tok nebo pamet druhe aplikace(nepamatuji si to presne).

Ma tedy tato funkcnost nejaky hlubsi vyznam? Pouziva se v produkci? Pokud to chapu dobre tak prideleni konkretniho jadra/threadu si resi jadro samo ne? Jde mi jednoduse o to zda je jeji prinos tak velky aby stala za tu zranitelnost nebo se uplne pletu?

Migrace procesu mezi jadry je efektivne zahozeni obsahu L1 a nesdilene L2, takze to ma veliky vykonnostni dopad.
A pak se stavaji nesmysly jako ze mate 16 jader, bezi tam 16 procesu naraz.. ale tim ze se stridaj a presouvaj, tak prichazite o vykon.

Z bezpecnostniho hlediska si dokazu predstavit, ze by si INIT prosadil zit v jedne pulce procesoru, a virtualky pod kvm/quemu v druhe pulce. Otazka je, zda volani ma i priznak pro dedeni nastaveni afinity.

>16 jader, bezi tam 16 procesu naraz.. ale tim ze se stridaj a presouvaj,

tých procesov by muzselo bzť max. 15 pre 16 jadro..
viď nižšie. Problém "skáčucej kravy"

A já jsem si doteď myslel, že plánovač je chytrý a každé vlákno spouští přednostně na CPU, na kterém doposuď běželo. Tedy pokud mám 16 jader a 16 procesů, že minimálně na 15 z nich nebude žádná migrace a na tom 16. se bude střídat kernel s tím jedním běžícím procesem.

Který plánovač? Moc se v nich nevyznám, ale pro Linux jich existuje více.

Požadavky na plánovač ale mohou být trochu protichůdné.

* Mám-li 16 jader a 16 procesů [možná spíše 16 vláken] (a pokud tyto procesy intenzivně vytěžují každý po jednom jádře CPU), pak Vámi navržené řešení se nechová férově k jednomu z procesů, který poběží pomaleji než ostatní.
* Mějme třeba čtyřjádro a jediný vytěžující proces. Je efektivní jej nechat na stejném jádře? Ne nutně, zvýší se mi teplota jednoho jádra, CPU pak bude throttlit. Po čase bude asi vhodné úlohu přehodit na jiné jádro.

u realtime systémů nebo při zpracování velkých stream dat (např. záznamy z kamer, replikace datových skladů) se třeba určují konkrétní jádra, na kterých běží aplikace, tyhle jádra zároveň vyřazuji z scheduleru, aby na ně nedal nic jiného. Nárust výkonu je v desítkách % u zatížených systémů, u těch nezatíženích to je těžko měřitelné.

hard RT(RTAI, RTLinuxPro, RT Preepmt patch) áno na ten som poukázal aj inde, ale je tu aj problém "skáčucej kravy", možno sa niekto pripravuje na tisícjadrové desktopy.

Môj Ryzen 5 1500X
276 tasks and 1906 threads

3.9 Merge window part 1

By Jonathan Corbet
February 20, 2013

A relatively simple scheduler patch fixes the "bouncing cow problem," wherein, on a system with more processors than running processes, those processes can wander across the processors, yielding poor cache behavior. For a "worst-case" tbench benchmark run, the result is a 15x improvement in performance.

https://lwn.net/Articles/538101/
Kernel Progress On Improving I/O Wait, Interactivity
Written by Michael Larabel in Linux Kernel on 4 March 2013

There's also a scheduler patch to fix a "bouncing cow" problem by when running fewer processes on the system than number of processor cores, the process could be bounced around between cores and yield poor performance. This bouncing cow fix for the scheduler yields a performance boost by 15x in a worst-case scenario. More work will come to future Linux kernel releases.
https://www.phoronix.com/scan.php?page=news_item&px=MTMxNzA

22. 1. 2020, 10:50 editováno autorem komentáře

Je to velke bzpecnostne riziko. Ale zas bude na vine Intel, nie vyvojari jadra vsakze.

V čem vidíš to riziko?

Je to úplně stejné "bezpečnostní riziko", jako u sched_setaffinity. Tohle API se (jestli jsem to dobře pochopil) akorát předvídatelněji chová v případě hotplug CPU.