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