lorsque schedule() revient ?

Question

Dans le cas d'une IO bloquante, par exemple la lecture d'un pilote, nous appelons wait_event_interruptible() avec une certaine condition. Lorsque la condition est remplie, la lecture est effectuée. J'ai examiné la fonction wait_event_interruptible(), elle vérifie la condition et appelle schedule(). schedule() recherche le prochain processus exécutable et effectue un changement de contexte et l'autre processus s'exécute. Cela signifie-t-il que la prochaine instruction à exécuter pour le processus en cours se trouvera à l'intérieur de la fonction schedule() lorsque ce processus sera à nouveau réveillé ?

1. Si oui, si plusieurs processus appellent volontairement schedule, alors tous les processus auront la prochaine instruction à exécuter une fois qu'ils auront été réveillés, sera-t-elle bien à l'intérieur de schedule() ?

2. En cas de ret_from_interrupt, schedule() est appelé. Quand reviendra-t-il ? car iret est exécuté après cela.

Answer 1

Je pense que la réponse à la première question est yes car il s'agit d'un moyen assez classique de mettre en œuvre le changement de contexte. C'est ainsi que fonctionne OS161 par exemple.

Si l'ordonnanceur est appelé à partir d'un ISR, tout devrait se passer de la même manière. L'ordonnanceur doit changer le contexte et retourner à l'ISR, et l'ISR doit alors retourner en utilisant la fonction IRET . Il reviendra à un processus/thread différent si l'ordonnanceur choisit de passer à un autre processus/thread et charge donc son contexte et sauvegarde l'ancien.

Answer 2

Point 2 : Le iret (retour du gestionnaire d'interruption) est exécutée, ce qui permet d'entrer dans le système de gestion de l'interruption. ret_from_interrupt . Ensuite, Linux passe le contrôle à la tâche suivante à exécuter ( schedule() ). L'une des considérations primordiales lors de l'écriture de gestionnaires d'interruption est que, pendant leur exécution, de nombreuses autres activités sont inhibées (d'autres interruptions, moins prioritaires, en sont le principal exemple), de sorte qu'il faut en sortir le plus rapidement possible. C'est pourquoi la plupart des gestionnaires d'interruptions se contentent de planquer le travail à effectuer avant de revenir, et ce travail est ensuite traité ailleurs (aujourd'hui dans un thread spécial du noyau).