Umím, pročetl jsem to.
Pokud to chápu, tak tickless jádro je preferované místo starého konceptu "periodic timer interrupt" jader a to zejména kvůli tomu, že je obtížné stanovit interval jak často se má jádro přerušovat běh obsluhou přerušení od časovače a pevná hodnota nemůže vyhovovat pro všechny druhy zátěže a pokud jsme na mobilních zařízeních tak je vyložené nepraktické cokoliv obsluhovat když to není potřeba a může se "spát".
Na odkazovaný článek navazuje trochu hutnější ,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/NO_HZ.txt.
Znamená to tedy, že dnes funguje na jádrech s dynamickým tickem a jádro si samo upravuje ja často má přijít přerušení od časovače dle potřeby aktuálně zátěže, pokud to chápu správně.
Je možné někde vyčíst jaká je "aktuální" hodnota, chápu, že se to asi velmi rychle mění.
Např. ve vmstat je ve sloupci system položka interrupt.
in: The number of interrupts per second, including the clock.
cs: The number of context switches per second.
Takže závěrem je, že to vlastně "tiká" celé kolem časovače v hardware (+ další zdroje přerušení).
Může být ale Linux i tedy na hardware, který nemá časovač jako zdroj přerušení (a jsou takové platformy ?), asi může, ale pokud by čekal na zdroj přerušení od něčeho co nechodí periodicky (nebo "plánovaně" periodicky) nedojde pak problém se preemptivností, nevím jak to napsat lepe, prostě nejde poté dobře rozdělovat čas plánování běhu úloh, protože úloha se nevzdá běhu pokud nechce a zrovna nepřichází žádný interrupt, který by vrátil řízení zpět jádru ?
Mark
3 Odpovědí
1538 Zhlédnutí