Ich bin kein Planer-Guru, aber ich möchte erklären, wie ich es sehe. Hier sind einige Dinge.
- preempt_disable() deaktiviert IRQ nicht . Es erhöht nur ein
thread_info->preempt_countvariabel. - Durch das Deaktivieren von Interrupts wird auch die Präemption deaktiviert, da der Scheduler danach nicht mehr funktioniert - aber nur auf einem Computer mit einer CPU. Auf dem SMP reicht es nicht, denn wenn Sie die Interrupts auf einer CPU schließen, tun die anderen / die anderen immer noch / etwas asynchron.
- Das Big Lock (bedeutet - das Schließen aller Interrupts auf allen CPUs) verlangsamt das System dramatisch - deshalb wird es nicht mehr verwendet. Das ist auch der Grund, warum preempt_disable() den IRQ nicht schließt.
Sie können sehen, was preempt_disable() ist. Versuchen Sie Folgendes:1. Holen Sie sich ein Spinlock.2. Zeitplan aufrufen()
In der dmesg sehen Sie so etwas wie "BUG:Scheduling While Atomic". Dies geschieht, wenn der Scheduler feststellt, dass sich Ihr Prozess in einem atomaren (nicht präventiven) Kontext befindet, sich jedoch selbst plant.
Viel Glück.
In einem Test-Kernel-Modul, das ich geschrieben habe, um eine Aufgabe zu überwachen/profilieren, habe ich versucht, Interrupts zu deaktivieren durch:
1 - Verwendung von local_irq_save()
2 - Verwendung von spin_lock_irqsave()
3 - Deaktiviere manuell_irq() für alle IRQs in /proc/interrupts
In allen 3 Fällen konnte ich immer noch den hrtimer verwenden, um die Zeit zu messen, obwohl IRQs deaktiviert waren (und eine Aufgabe, die ich überwachte, wurde ebenfalls verhindert).
Ich finde das veeeeerrrryyyy seltsam ... Ich persönlich habe erwartet, was Sebastian Mountaniol darauf hingewiesen hat -> Keine Unterbrechungen - keine Uhr. Keine Uhr - keine Timer...
Linux-Kernel 2.6.32 auf einem einzelnen Kern, einer einzelnen CPU... Kann jemand eine bessere Erklärung haben?