qui n'est pas fourni avec le kernel standard de Debian
Tu veux dire que le noyau fourni par défaut sous Debian n’est pas configuré avec CONFIG_RT_GROUP_SCHED ? Si c’est le cas, alors la méthode d’Anthony devrait marcher.
Pour rappel, il y a deux façons incompatibles de donner des privilèges temps-réels à un processus sous Linux, selon que CONFIG_RT_GROUP_SCHED soit activé ou non.
Sans CONFIG_RT_GROUP_SCHED, un processus demande une politique d’ordonnancement temps-réel (SCHED_FIFO ou SCHED_RR) et une priorité en appelant sched_setscheduler(2). Le système accède à cette demande si le processus est autorisé, c’est-à-dire si la "resource limit" RLIMIT_RTPRIO associée à ce processus est supérieure à la priorité demandée. En règle générale, la limite RLIMIT_RTPRIO (comme toutes les autres "resource limits") pour un utilisateur donné est définie à la connexion de ce dernier, via un module PAM qui applique des règles décrites dans /etc/security/limits.conf.
Si le noyau est compilé avec CONFIG_RT_GROUP_SCHED, un processus obtient une politique d’ordonnancement temps-réel de facto en se plaçant (ou en étant placé) dans un cgroup auquel on a attribué une « fraction de temps réel » (paramètre cpu.rt_runtime_us > 0).
Les deux méthodes sont incompatibles parce que la seconde invalide complètement la première : si CONFIG_RT_GROUP_SCHED est activé, demander et obtenir une politique d’ordonnancement temps réel avec sched_setscheduler(2) ne sert à rien tant que le processus n’est pas placé dans un cgroup avec un cpu.rt_runtime_us non-nul (le piège étant que l’appel à sched_setscheduler(2) n’échoue pas — pour le processus, tout semble se passer comme s’il avait bel et bien obtenu la politique d’ordonnancement qu’il demandait). Inversement, une fois un processus placé dans un cgroup « temps réel », il a de facto une politique d’ordonnancement temps réel même s’il ne l’a pas explicitement demandé.
[^] # Re: Scheduler Temps reel
Posté par gouttegd . En réponse au message Les cgroups et systemd. Évalué à 2.
Tu veux dire que le noyau fourni par défaut sous Debian n’est pas configuré avec CONFIG_RT_GROUP_SCHED ? Si c’est le cas, alors la méthode d’Anthony devrait marcher.
Pour rappel, il y a deux façons incompatibles de donner des privilèges temps-réels à un processus sous Linux, selon que CONFIG_RT_GROUP_SCHED soit activé ou non.
Sans CONFIG_RT_GROUP_SCHED, un processus demande une politique d’ordonnancement temps-réel (SCHED_FIFO ou SCHED_RR) et une priorité en appelant sched_setscheduler(2). Le système accède à cette demande si le processus est autorisé, c’est-à-dire si la "resource limit" RLIMIT_RTPRIO associée à ce processus est supérieure à la priorité demandée. En règle générale, la limite RLIMIT_RTPRIO (comme toutes les autres "resource limits") pour un utilisateur donné est définie à la connexion de ce dernier, via un module PAM qui applique des règles décrites dans
/etc/security/limits.conf.Si le noyau est compilé avec CONFIG_RT_GROUP_SCHED, un processus obtient une politique d’ordonnancement temps-réel de facto en se plaçant (ou en étant placé) dans un cgroup auquel on a attribué une « fraction de temps réel » (paramètre cpu.rt_runtime_us > 0).
Les deux méthodes sont incompatibles parce que la seconde invalide complètement la première : si CONFIG_RT_GROUP_SCHED est activé, demander et obtenir une politique d’ordonnancement temps réel avec sched_setscheduler(2) ne sert à rien tant que le processus n’est pas placé dans un cgroup avec un cpu.rt_runtime_us non-nul (le piège étant que l’appel à sched_setscheduler(2) n’échoue pas — pour le processus, tout semble se passer comme s’il avait bel et bien obtenu la politique d’ordonnancement qu’il demandait). Inversement, une fois un processus placé dans un cgroup « temps réel », il a de facto une politique d’ordonnancement temps réel même s’il ne l’a pas explicitement demandé.