Warum die Deaktivierung von Interrupts die Kernel-Vorbelegung deaktiviert und wie die Spin-Sperre die Vorbelegung deaktiviert

8

Ich lese Linux Kernel Entwicklung vor kurzem, und ich habe ein paar Fragen im Zusammenhang mit der Deaktivierung der Vorkaufsrechte.

  1. Im Abschnitt "Interrupt Control" in Kapitel 7 heißt es:

      

    Darüber hinaus deaktiviert das Deaktivieren von Interrupts auch die Kernel-Vorbelegung.

    Ich lese auch aus dem Buch, dass Kernel Preemption in den folgenden Fällen auftreten kann:

      

    Wenn ein Interrupt-Handler beendet wird, bevor er zum Kernel-Space zurückkehrt.
      Wenn Kernel-Code wieder präemptiv wird.
      Wenn eine Task im Kernel explizit schedule ()
    aufruft   Wenn eine Task in einem Kernel blockiert (was zu einem Aufruf von schedule () führt)

    Aber ich kann Interrupts nicht mit diesen Fällen in Verbindung bringen.

  2. Soweit ich weiß, würde ein Spinlock die Vorbelegung mit der Funktion preempt_disable () deaktivieren.

    Der Beitrag Was genau sind "Spin-Locks"? sagt:

      

    Auf einer Single-Core-Maschine ist ein Spinlock einfach ein "disable interrupts" oder "raise IRQL", was die Thread-Planung komplett verhindert.

    Schaltet preempt_disable () die Vorbelegung durch Deaktivierung von Interrupts aus?

feirainy 25.12.2013, 06:32
quelle

2 Antworten

7

Ich bin kein Scheduler-Guru, aber ich würde gerne erklären, wie ich es sehe. Hier sind einige Dinge.

  1. preempt_disable () deaktiviert IRQ nicht . Es erhöht nur eine thread_info->preempt_count Variable.
  2. Durch das Deaktivieren von Interrupts wird auch die Vorbelegung deaktiviert, da der Scheduler danach nicht mehr funktioniert - jedoch nur auf einem Einzel-CPU-Rechner. Auf dem SMP ist es nicht genug, denn wenn Sie die Interrupts auf einer CPU schließen, tut / tun die anderen / anderen noch etwas asynchron.
  3. Die große Sperre (bedeutet - alle Interrupts auf allen CPUs schließen) verlangsamt das System drastisch - deshalb wird es nicht mehr benutzt. Dies ist auch der Grund, warum preempt_disable () den IRQ nicht schließt.

Sie können sehen, was preempt_disable () ist. Versuche dies: 1. Holen Sie sich einen Spinlock. 2. Anrufliste ()

Im dmesg werden Sie etwas wie "BUG: Scheduling atomic" sehen. Dies geschieht, wenn der Scheduler erkennt, dass Ihr Prozess im atomaren (nicht präemptiven) Kontext läuft, aber sich selbst plant.

Viel Glück.

    
Sebastian Mountaniol 26.12.2013, 16:08
quelle
1

In einem Kernel-Testmodul, das ich geschrieben habe, um eine Aufgabe zu überwachen / zu profilieren, habe ich versucht, Interrupts zu deaktivieren durch:

1 - Verwenden von local_irq_save ()

2 - Verwenden von spin_lock_irqsave ()

3 - Manuell disable_irq () für alle IRQs in / proc / interrupts

In allen 3 Fällen konnte ich den hrtimer immer noch verwenden, um die Zeit zu messen, obwohl IRQs deaktiviert waren (und eine Aufgabe, die ich überwachte, wurde ebenfalls vorweggenommen).

Ich finde das veeeeeerrrryyyy komisch ... Ich persönlich habe erwartet, worauf Sebastian Mountaniol hingewiesen hat - & gt; Keine Unterbrechungen - keine Uhr. Keine Uhr - keine Timer ...

Linux Kernel 2.6.32 auf einem Single-Core, Single-CPU ... Kann jemand eine bessere Erklärung haben?

    
fakr00n 11.02.2014 16:15
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Behandelt php gleichzeitig Anfragen in Multithread- oder Multiprocess-Manier?