Bonjour,
Première question Quand on créé un kernel thread avec kthread_create est il par défaut en mode SCHED_OTHER.
Deuxième question un kernel thread créer par kthread_create est il toujours plus prioritaire qu'un user thread créé par pthread_creat quelque soit le mode de chacun des threads (SCHED_OTHER,SCHED_RR,SCHED_FIFO,..)?
Troisième question si kernel thread a une priorité 10 en mode SCHED_FIFO et un user Thread a une priorité 20 en mode SCHED_FIFO est ce que le thread user est plus prioritaire que le kernel thread?
Quatrième question dans un driver si on utilise request_threaded_irq on peut voir (linux version 3.10.5) dans /kernel/irq/manage.c que la création du thread se fait dans __setup_irq et que c'est dans le thread lui même que le changement de priorité 50 et de mode (SCHED_FIFO) est fait voir fonction irq_thread. N'y a t'il pas un risque que entre le début du thread et le changement de priorité, des thread USER qui sont en mode fifo et pourtant de priorité plus faible (moins que 50) prennent la main?
Remarque dans un commit 3 juin 2013 ils ont corrigé se problème pour les version supèrieur de liinux
"When a threaded irq handler is installed the irq thread is initially
created on normal scheduling priority. Only after the irq thread is
woken up it sets its priority to RT_FIFO MAX_USER_RT_PRIO/2 itself.
This means that interrupts that occur directly after the irq handler
is installed will be handled on a normal scheduling priority instead
of the realtime priority that one would expect.
Fix this by setting the RT priority on creation of the irq_thread"
Merci d'avance pour vos réponse
Bonne journée
Yodalesage
# Question étrange
Posté par Kerro . Évalué à 2.
Je n'ai pas les réponses à tes questions, mais on n'utilise par un kernel thread pour les mêmes besoin qu'un user tread.
Ton choix doit être basé sur le besoin, pas sur d'hypothétiques performances.
# réponse à question etrange
Posté par yodalesage . Évalué à 3.
L' application embarqué sur laquelle je travaille utilise un driver qui utilise une requeste irq ce qui inclut un kernel thread.
De plus cette application à l'obligation hiérarchiser ces threads. Certain thread comme la sauvegarde, la gestion d'acquisition doivent absolument être plus prioritaire que l'ihm. Et ça ce n'est qu'une petite partie. Enfin le driver en question est le driver de base de l'acquisition donc comme les thread acquisition coté USER il doit aussi être prioritaire vis à vis d'autre thread comme L'IHM (d'ou la question un thread kernel vis à vis d'un thread user).
L'idée à la base était de tous passer l'application en mode SCHED_FIFO (coté user) ce qui permettait de contrôler complètement la hiérarchisation. Mais ça ne marchais pas exactement comme je le souhaitais si l'ihm avait un gros travaille je voyais que l'acquisition flanchait.Au début j'ai cru à un problème d'inversion de priorité avec les mutex mais ce n'était pas cela. Et c'est en regardant le driver d'acquisition (que je n'ai pas conçu) que j'ai compris lui aussi utilisait un thread. Et c'est de la que sont venu toutes mes questions. Donc je pense que le problème vient de cette creation de thread et de ce changement de priorité tardif. Mais j'ai résolu autrement mon problème en mettant tous les thread de très faible priorité en mode SCHED_OTHER. Mais bon je posais toutes ces questions pour vraiment sur. Et c'était aussi pour ma culture personnel.
Merci de ta réponse bonne journée.
Yodalesage.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.