Discussion :

[granquet]

je travaille sur un kernel 2.6.17 sur une target sh4 et j'observe des latences réguliéres sur mes échanges avec un socket unix quand le cpu est fortement utilisé.

une image vaut mieux que 1000 mots


X: le temps mesurée depuis le lancement de l'application
Y: le temps de réponse de mes comm socket
rouge: résultat en charge (cpu utilisé)
vert: résultat à vide (rien d'autre que ma comm socket ne tourne)

un superbe peigne, bien régulier avec des latences de 200ms (énorme pour mon utilisation)

les tests réalisés :
activer/desactiver la preemption dans le kernel ne change rien

une attente active entre chaque appel n'as aucun effet positif

le passage à des sockets non bloquants montre qu'aucun send n'est bloquant, et donc aucune attente due au buffer d'envoie plein (RPC avec 'ACK' explicite)

par contre:

passer les taches en policy SCHED_FIFO supprime entiérement le probléme


un usleep(0) entre chaque appel fait disparaitre le peigne.
un usleep(0) met la tache en sleep jusqu'au prochain tick systéme
un de ses effets de bord serait de provoquer un context switch si une autre tache est runnable (supposé)
remplacer usleep(0) par un yield periodique (tous les 1000 appels par exemple) produit un résultat similaire (plus de peigne, seulement quelques appels avec forte latence)

le passage au kernel 2.6.23:

les latences ne semblent pas être reproductible (les 3 modéles de kernel preempt ont été essayé)
par contre le temps de réponse moyen est beaucoup plus élevé, ce qui ralonge considérablement la durée totale du test (environ 30%)



les changements qui pourraient impacter:
-changement de la classe des locks sur AF_UNIX en bh (http://lkml.org/lkml/2006/6/5/340 voir http://oreilly.com/catalog/linuxdrive3/book/ch05.pdf chapitre spinlock) => à prioris mis hors de cause avec un test sur la family AF_INET (qui utilise toujours la meme classe de lock)
-refonte complete du scheduler pour les taches SCHED_OTHER => supposé 'coupable' (de l'amélioration de comportement) pour le moment (voir : http://kerneltrap.org/node/8059 pour les détails)


j'aimerais bien un avis éclairé sur le problème
pour moi le scheduling des policies SCHED_NORMAL du 2.6.17 est en cause
le problème étant de trouver une astuce pour garder le 2.6.17 et une policy SCHED_NORMAL car je ne fait que des RPC avec mes sockets, et d'autres choses plus gourmandes et plus prioritaires tournent, donc à prioris passer en SCHED_{RR,FIFO} n'est pas une bonne solution.
au mieux, j'aimerais trouver une solution pour garder mon kernel 2.6.17 (sans trop le hacker)


ci-joint alt-cli et alt-serv, mes clients et server de test utilisés pour plotter les graphes présentés.
ps: si tu es experte kprobe/jprobe où LTTng sur target sh4, tu m'interresse

[Tchetch]

Salut,

Peut-être prendre le 2.6.18 :

Originally, Standard Linux was intended as a general-purpose operating
system being able to handle background processes, interactive applica‐
tions, and less demanding real-time applications (applications that
need to usually meet timing deadlines). Although the Linux kernel 2.6
allowed for kernel preemption and the newly introduced O(1) scheduler
ensures that the time needed to schedule is fixed and deterministic
irrespective of the number of active tasks, true real-time computing
was not possible up to kernel version 2.6.17.

Real-time features in the mainline Linux kernel
From kernel version 2.6.18 onwards, however, Linux is gradually becom‐
ing equipped with real-time capabilities, most of which are derived
from the former realtime-preempt patches developed by Ingo Molnar,
Thomas Gleixner and others. <...>

[granquet]

il n'est pas vraiment sain (de mon point de vue) de passer les tache en policy RT.

on peux en discuter, mais mon but ultime n'est pas de faire des RPCs, et passer les RPCs en RT risquerais d'avoir des effets de bord génants sur le reste des applications (chose à éviter à tout prix)

quand à changer de kernel, malheureusement je ne peux pas, je dois me contenter du 2.6.17.

[Tchetch]

on peux en discuter, mais mon but ultime n'est pas de faire des RPCs, et passer les RPCs en RT risquerais d'avoir des effets de bord génants sur le reste des applications (chose à éviter à tout prix)

Ok. Et l'ordonnanceur IO, il a un impact. Si tu utilises noop ?

[granquet]

l'ordonanceur IO n'as d'impact que sur les blockdevices (IDE,SATA...)

par contre ça souléve une autre question: est-ce que QoS est applicable aux socket unix?

[bizulk]

Bonjour,

Bravo pour la qualité du post, qui le rend bien plus intéressant. Au passage comment tu as obtenu tes graph ?
Je dirais que dans un contexte d'ordonnancement FIFO la priorité de ta tâche ne varie pas et est plus prioritaire que les autres processus placé en ordonnancement SCHED_NORMAL, d'où le résultat sur les performances.
En sched normal la priorité de ta tâche varie () et suivant ses demandes en ressources processeur le scheduler va donner la donner la main a une tache moins gourmande en ressource, à chaque fois que tu fais ton appel système sur la socket par exemple.

A mon avis il y a deux manières de compenser le problème en conservant l'ordonnancement Linux classique :
- Celui que tu as mis en place avec usleep() et shced_yield() : en rendant la main a l'ordonnance tu 'conserves' ta priorité.
- Lance ta tâche avec une priorité statique plus forte (nice), ou moins forte.

N'hésite pas a poster le résultat.
++

[fmoreau]

Salut,

un usleep(0) met la tache en sleep jusqu'au prochain tick systéme

C'est specifie ou ce comportement de sleep() ?

[granquet]

C'est specifie ou ce comportement de sleep() ?

dans les source du kernel (fin, ce que j'en ai compris)

[nicolas.sitbon]

dans les source du kernel (fin, ce que j'en ai compris)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#include <unistd.h>
int usleep(useconds_t useconds);

If the value of useconds is 0, then the call has no effect.

[fmoreau]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#include <unistd.h>
int usleep(useconds_t useconds);

Si granquet dit vrai alors linux n'est pas tres posix dans ce cas...

[fmoreau]

dans les source du kernel (fin, ce que j'en ai compris)

ca m'a l'air vrai sauf si tu as le support des high resolution timers...

[granquet]

If the value of useconds is 0, then the call has no effect.

je n'ai retrouvé ce commentaire dans mes sources.
chez moi usleep est un simple wrapper de nanosleep

j'utilise les hrtimers
et de ce que je vois du code (dispo ici: http://lxr.linux.no/linux+v2.6.17.14...hrtimer.c#L773 )
schedule() est effectivement appelé (même avec une valeur de 0 dans usleep)