Je ne suis pas un gourou de l'ordonnanceur, mais je voudrais expliquer comment je le vois. Voici plusieurs choses.
- preempt_disable() ne désactive pas l'IRQ . Il augmente juste un
thread_info->preempt_countvariables. - La désactivation des interruptions désactive également la préemption car le planificateur ne fonctionne plus après cela, mais uniquement sur une machine à un seul processeur. Sur le SMP, ce n'est pas suffisant car lorsque vous fermez les interruptions sur un processeur, l'autre / les autres font toujours / font quelque chose de manière asynchrone.
- Le Big Lock (signifie - fermer toutes les interruptions sur tous les processeurs) ralentit considérablement le système - c'est pourquoi il n'est plus utilisé. C'est aussi la raison pour laquelle preempt_disable() ne ferme pas l'IRQ.
Vous pouvez voir ce qu'est preempt_disable(). Essayez ceci :1. Obtenez un spinlock.2. Planification des appels()
Dans le dmesg, vous verrez quelque chose comme "BUG :planification pendant qu'atomique". Cela se produit lorsque le planificateur détecte que votre processus est dans un contexte atomique (non préemptif) mais qu'il se planifie lui-même.
Bonne chance.
Dans un module de test du noyau que j'ai écrit pour surveiller/profiler une tâche, j'ai essayé de désactiver les interruptions en :
1 - Utilisation de local_irq_save()
2 - Utiliser spin_lock_irqsave()
3 - Désactiver manuellement_irq() à tous les IRQ dans /proc/interrupts
Dans les 3 cas, je pouvais toujours utiliser le hrtimer pour mesurer le temps même si les IRQ étaient désactivés (et une tâche que je surveillais a également été préemptée).
Je trouve cela étrange veeeeerrrryyyy ... Personnellement, j'anticipais ce que Sebastian Mountaniol a souligné -> Pas d'interruption - pas d'horloge. Pas d'horloge - pas de minuteries...
Noyau Linux 2.6.32 sur un seul cœur, un seul CPU... Quelqu'un peut-il avoir une meilleure explication ?