C'est déjà le cas. Il y a dans le noyau, depuis la version 2.6.19 (ou 2.6.20 ?) les fonctions round_jiffies() et round_jiffies_relative() qui arrondissent à la seconde pleine les valeurs de jiffies passées en argument.
L'idée est que dans de très nombreux cas, on a besoin de programmer une tâche dans le futur, ou à intervalle régulier, mais on n'a pas nécessairement besoin que la date d'exécution de cette tache soit vraiment précise à la fraction de seconde près. On souhaite seulement que « cet (évènement|tache à exécuter) ai lieu approximativement (dans|toutes les) X seconde(s) ».
Ainsi, si nous avions 10 pilotes de périphériques différents qui programmaient l'exécution d'une tâche toutes les secondes environ, mais n'avaient pas initialisé leurs timers en même temps (ou bien avec un intervalle légèrement différent), ils réveillaient le noyau 10 fois par seconde. Si ces 10 pilotes sont modifiés pour programmer leur réveil à une date arrondie avec round_jiffies, ils s'exécuteront en même temps, causant un seul réveil par seconde (un seul réveil à la seconde entière, qui, au passage, aurai de toutes façon eu lieu, même en l'absence de ces 10 pilotes, car il y a déjà d'autres choses converties au round_jiffies).
Il reste beaucoup de travail pour tirer pleinement parti de cette nouvelle API partout où le noyau pourrait le faire, mais certains y travaillent visiblement, et chaque petite conversion réduit le nombre de réveils par seconde dont le noyau à besoin.
Note : s'il y a des développeurs GTK/Gnome dans le coin : c'est exactement comme g_timeout_add_seconds_full() ou g_timeout_add_seconds() (au lieu de g_timeout_add()). Cette fonction permet d'économiser de l'énergie en réduisant les réveils de la CPU, car elle regroupe tout les évènements programmés à la prochaine seconde entière. Svp, si vous n'avez pas besoin d'une granularité/précision très fine, par ex. si vous avez besoin de programmer une action « approximativement toutes les X secondes », préférez utiliser celle-ci au lieu de g_timeout_add().
[^] # Re: CFS dans 2.6.23 !
Posté par herodiade . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 6.
L'idée est que dans de très nombreux cas, on a besoin de programmer une tâche dans le futur, ou à intervalle régulier, mais on n'a pas nécessairement besoin que la date d'exécution de cette tache soit vraiment précise à la fraction de seconde près. On souhaite seulement que « cet (évènement|tache à exécuter) ai lieu approximativement (dans|toutes les) X seconde(s) ».
Ainsi, si nous avions 10 pilotes de périphériques différents qui programmaient l'exécution d'une tâche toutes les secondes environ, mais n'avaient pas initialisé leurs timers en même temps (ou bien avec un intervalle légèrement différent), ils réveillaient le noyau 10 fois par seconde. Si ces 10 pilotes sont modifiés pour programmer leur réveil à une date arrondie avec round_jiffies, ils s'exécuteront en même temps, causant un seul réveil par seconde (un seul réveil à la seconde entière, qui, au passage, aurai de toutes façon eu lieu, même en l'absence de ces 10 pilotes, car il y a déjà d'autres choses converties au round_jiffies).
Il reste beaucoup de travail pour tirer pleinement parti de cette nouvelle API partout où le noyau pourrait le faire, mais certains y travaillent visiblement, et chaque petite conversion réduit le nombre de réveils par seconde dont le noyau à besoin.
Note : s'il y a des développeurs GTK/Gnome dans le coin : c'est exactement comme g_timeout_add_seconds_full() ou g_timeout_add_seconds() (au lieu de g_timeout_add()). Cette fonction permet d'économiser de l'énergie en réduisant les réveils de la CPU, car elle regroupe tout les évènements programmés à la prochaine seconde entière. Svp, si vous n'avez pas besoin d'une granularité/précision très fine, par ex. si vous avez besoin de programmer une action « approximativement toutes les X secondes », préférez utiliser celle-ci au lieu de g_timeout_add().