Administrace komentářů

Volba HZ nemá žádný vliv na frekvenci plánování. Nemá žádný vliv na odezvu systému. Nemá žádný vliv na nic. Většina pověr, které o ní kolují, pochází asi tak z dávných dob, kdy ještě nějaký vliv měla. Donedávna na ní třeba záviselo, jak moc často RCU spouští své drobné „reclamation“ úlohy na pozadí a další „housekeeping“. Ale ani to už dnes neplatí. Kernely jsou dnes většinou tickless; nicméně i v době, kdy nebyly, se uspávání, probouzení a plánování dělo s granularitou nesrovnatelně menší než 100 Hz, 1000 Hz nebo cokoliv podobného. Dojde-li k migraci vlákna na jiný procesor, kde se má vlákno zase spustit, stane se to okamžitě, ne až za chvíli. Paket ze sítě, požadavek od uživatele a obecně všechno, co vyvolá IRQ, se vyřeší okamžitě, bez ohledu na volbu HZ. Hardwarové časovače, které se používají někde v implementaci API jako je nanosleep(), taktéž nemají absolutně žádnou souvislost s volbou HZ. IRQ (nebo jiný typ přerušení) od časovače i případné probuzení procesu, který spal, se ošetří okamžitě, tedy přesněji řečeno, hned, jakmile to bude možné. Nikdy se nikde nečeká setinu vteřiny nebo něco takového. Volba HZ je dnes spíš relikt z minulosti než cokoliv užitečného.

Neni problem cekat ve smycce kratsi dobu, ale jakmile pustis cpu musis pocitat ze se nedostanes k lizu driv nez zase za 1/CONFIG_HZ sekund.

Naprostý nesmysl.

A to jen kdyz na dalsi slice nevybere planovac zase jinou ulohu.

Naprostý nesmysl. Tohle už je fakt ve stylu Vesmírní Lidé.

Do techhle veci moc nevidim, ale zni mi to jako ze potrebujes RT kernel.

Tento výrok přichází se zpožděním několika dnů. Hodil by se na 1. dubna. Ale vážně, kdyby platilo cokoliv z toho, co tu tvrdíš, nikdo by dnes nepoužíval počítače a raději by dal přednost telegrafu.