Google-ingenieur Qais Yousef heeft zondag een patch uitgebracht waarin wordt voorgesteld om de standaard timerfrequentie van de Linux-kernel te verhogen van 250 Hz naar 1000 Hz. De Google-ingenieur is van mening dat de huidige standaardfrequentie van de Linux-kernel problemen kan veroorzaken bij planningsbeslissingen, zoals onnauwkeurige tijdsegmenten, vertragingen in de taakverdeling, vertragingen bij het bijwerken van statistieken en andere gerelateerde problemen. QaisYousef is van mening dat het voor de kernel beter is om een ​​standaardfrequentie van 1000 Hz aan te nemen:

"Een veel voorkomende schermconfiguratie zoals Android- en desktopsystemen is 120 Hz. Dit geeft de taak 8 ms om aan te werken. 4 ms is de helft van die tijd, waardoor de last van het nemen van zeer goede beslissingen over het ontwaken zwaarder wordt dan nodig. Het maakt het ook moeilijker om het systeem efficiënt te gebruiken om optimale prestaties / watt te behouden. We proberen bijvoorbeeld de DVFS-headroom te definiëren als een functie van TICK, omdat deze het worst case scenario definieert voor het bijwerken van statistieken. Een grotere TICK betekent dat we de frequentie te agressief moeten verhogen als we ervoor willen zorgen dat de prestaties niet worden beïnvloed, maar als de taak niet alle fragmenten uitput, verliezen we de mogelijkheid om een lagere frequentie te gebruiken en energie te besparen.

Over het algemeen worden de deadlines voor de werklast korter, en dit is niet uniek voor de UI-pijplijn.

Ik geloof dat HZ_250 de standaardinstelling is als afweging voor batterijvermogen in apparaten die misschien niet van frequente TICKS houden die de batterij onnodig leeg kunnen maken. Maar voor zover ik het begrijp, zou de huidige NOHZ-status voldoende moeten zijn om deze zorgen weg te nemen. De recente toevoeging van RCU_LAZY helpt verder om langere TICKs te behouden in inactieve scenario's.

Zoals Saravana mij heeft uitgelegd, helpt een langere TICK indirect de cohesie van de timer, wat betekent dat het problemen kan maskeren met stuurprogramma's/taken die frequente timing vereisen, waardoor toegang tot diepere inactieve staten wordt voorkomen (voor veel systemen is 4 ms een hogere waarde die toegang tot diepere inactieve staten mogelijk maakt). Maar je zou ook kunnen beargumenteren dat dit het probleem is met deze stuurprogramma's/taken.

Snellere TICK kan nog steeds resulteren in een hoger vermogen, maar niet als gevolg van TICK-activiteit. Het systeem reageert beter (zoals verwacht) en de verblijftijden op hogere frequenties zullen naar verwachting hoger zijn, omdat ze per ongeluk op lagere frequenties blijven hangen. De series in [1] proberen de manier waarop de planner omgaat met de responssnelheid te verbeteren en bieden gebruikers/applicaties manieren om beter aan hun behoeften te voldoen, inclusief het afmelden voor adequate respons (in de bovenstaande serie is ramup_multiplier 0)"

De frequentie van de Linux-kerneltimer is lange tijd een bron van discussie en verschillende meningen geweest. Maar nu is de standaardfrequentie 1000 Hz in plaats van 250 Hz, wat logisch lijkt.

Er wordt nu een patch ter beoordeling/discussie ingediend om de standaardfrequentie te wijzigen.