Nebude to spíš o tom, že se budou na nové úlohy prioritně používat jádra, která jsou výkonnější a na ta další jádra se sáhne až když to nepůjde jinak? Těch 94 % nedává smysl. Když úloha poběží minutu a během toho jednou změní jádro, tak asi nebude o 94 % pomalejší. To je právě úděl scheduleru, aby zvážil všechna pro a proti a nemyslím si, že by to bylo nakonec horší.
8. 9. 2023, 11:48 editováno autorem komentáře
Kdyby sis to precet, tak vis, ze presne takto to fungova nema, ma se "trvale" sledovat zatizeni jader, a to znamena je trvale zatezovat.
Pricemz planovac v kernelu je behem poslednich let pomerne v mode, a pokazde prijde nekdo s necim ubermegauzasnym ... aby se po par mesicich s prekvapenim zjistilo, ze to bud nefunguje vubec nebo to jeste navic ma bezpecnostni bugy.
V realnym svete je presun ulohy vzdy to nejhorsi, co muzes udelat.
"V realnym svete je presun ulohy vzdy to nejhorsi, co muzes udelat."
A na to jste přišel jak?
Víte jak dlouho trvá přehození úlohy?
A jak často se to děje?
Je to pár cyklů. Což je na 4GHz CPU zanedbatelný čas. Pohledem do scheduleru vidím že se to děje jednou za cca 10 vteřin.
Můj odhad:
Ztráta je jedno promile výkonu.
Ale získá i 10%
Zkoušel jsem nastavit afinitu. A výkon šel o 10% dolů.
4GHz = 4 000 000 000 cyklů za vteřinu.
Chápu že milion se někomu může zdát hrozně moc. Ale pro CPU vyrobené v tomto století to je tisícina vteřiny.
Když vezmu v úvahu že dnešní CPU zvládají víc operací za takt a takty kolem 5GHz...
Nic. Jinak.
Jde o přesouvání. Aplikace bude mít v cache asi tak 1MB = 1 000 000 bajtů. Moc víc to nebude. (L3 mívá desítky MB ale bývá sdílená mezi jádry. L1 a L2 mají řádově megabajty. Ale nemusí být využita celá. )
Jak dlouho bude trvat přesunout milion bajtů?
Já to sice nevím. Ale předpokládám že to budou nějaké ty milisekundy. Takže přehození jednou za sekundu nemáte šanci poznat.