Salut,

Est-ce que quelqu'un sait comment est réalisée l'ordonnancement de processus ? Et plus particulièrement le réveil de ceux-ci.

Supposons que j'ai, entre autre, un processus qui travaille peu car il passe la plupart de son temps à attendre des sockets dans un appel select. Mais, j'aimerais que lorsque l'une de ses socket soit prête alors il s'active le plus vite possible et avec une grande priorité. Si j'augmente la priorité de ce processus aurais-je l'effet désiré ? I.e. est-ce que le système s'apercevra qu'il peut être réveillé dès qu'une socket est prête. Et aussi, est-ce que ça pourrait nuire à la performance globale du système : si le processus a une priorité plus élevé, est-ce qu'il va être réveillé plus souvent par le système _avant_ qu'une socket ne soit prête (pour être rendormie juste après) ou alors est-ce que ce genre de chose est très bien gérée et ne se produit pas ?

Il me semble que le scheduler de linux favorise les processus qui sont bloqués sur des I/O (afin j'ai lu ça dans un truc pas tout jeune, je ne sais pas si c'est toujours vrai). Mais comment peut-on s'assurer qu'un processus bénéficie bien de cette politique ?

Je suis aussi preneur d'un pointeur vers quelque chose qui parle de ce genre de question si vous en avez, car je n'ai pas trop d'idée sur où trouver ces infos (ailleurs que dans les sources de linux).

Merci

D'après ce que je sais :

1) le scheduler n'est pas unique. Il faut voir lequel a été choisi lors de la compilation du noyau.
2) il y a(vait ?) une option pour jouer sur la "réactivité" du système.
3) pourquoi n'utiliserais-tu pas nive pour donner une priorité maximale à ton processus ? (ok, ça nécessite les droits root mais bon…)

nice*

(je ne suis pas encore réveillé moi )

Quand je faisais joujou avec une lib de calcul haute perf, je passais mon processus en real-time avec un appel a sched_setscheduler avec FIFO comme parametre. Cette priorite est la plus violente qui existe. Si le processus devient 'runnable' le noyau preempte immediatement autant de processus que neccaissaire pour faire tourner le processus real-time. Comme tu peux te douter. C'est extremement violent et ca sature autant de CPU que tu as de process. Et si tu as une boucle infini, tu ne pourras pas killer le processus puisque tu ne pourra pas de logguer. Il faut alors faire utiliser une kernel trap. Tu peux aussi utiliser la policy RR qui fait du round robin parmis les processus Realtime et placer un serveur ssh la bas pour pouvoir avoir un shell real time.

En fait, assez spécifiquement ma question était de savoir si un programme qui a une très grosse priorité mais qui est bloqué dans un select (ou autre) occupe du CPU (ou en occupe plus que le même qui n'aurait pas une telle priorité). De la réponse de godrik, j'ai l'impression que non (et puis je pourrais faire un test, c'est vrai).

Chris : oui, de-nicer mes processus est ce que je ferais. C'est dommage que le système de fichier ne gère pas encore les "capabilities" sinon il n'y aurait pas besoin d'être root pour faire ça.

select est un appel bloquant, le processus est dans un etat de sommeil (je ne sais plus le terme adequat) quand tu attend sur select. Il sera reveille par le noyau quand il y aura des choses a lire. Cependant, c'est possible qu'il ne s'endorme pas immediatement. Il y a plein de politique dans le noyau d'attente active pendant X millisecondes avant de passer en attente passive. C'est ce qui est fait par exemple pour les mutex. Peut etre qu'il y a un comportement similaire pour select.