Linux 2.6 Planung und Vorkaufsrecht - preempt_count Verwendung

Question

Eine kleine Diskussion vor der Frage. Der Kernel von Linux 2.4 ist nicht präemptiv. Wenn also im Kernelmodus ein Systemaufruf procedent wird, setzen wir nur set_need_resched, um ein Flag zu setzen, und dann, wenn wir zurück in den Benutzermodus gehen, prüfen wir das flag und mache Kontextwechsel.

Lässt man das mit Linux 2.6 vergleichen, das preemptive Kernel hat. Wir können nicht einfach Kernel 2.4 nehmen und set_need_resched (raising flag) in schedule() umwandeln (also in linux kernel 2.6 gibt es einen Zähler preempt_count, der sich jedes Mal bei spin_lock() erhöht und verringert auf spin_unlock().

Eigentlich, dieses Feld "preempt_count" bestimmen, ob der Kernel ausgeschlossen werden kann. Zum Beispiel auf einem von der Uhr Rückkehr unterbrechen, wenn die Bedingung:

(current->need_resched == 1) && (current->preempt_count == 0) 

wahr ist, dann der Kern führt kontext Schalter.

Die Frage ist, warum der Kernel von Linux 2.6 Preemption verhindert, wenn eine Sperre vom Typ Spinlock gehalten wird.

Was ist das Szenario, das passieren könnte, wenn der Kernel die Vorbelegung nicht verhindert? Können Sie mir so detailliert wie möglich ein konkretes Beispiel geben?

Vielen Dank.

Answer 1

Haben Sie über Schlafschlösser wie Mutexe oder Semaphoren gelesen?

In ihrem Fall, wenn die Sperre nicht genommen werden kann, kann sich der Thread selbst schlafen legen und z.B. verleihen ihm seine Priorität, so dass der Schließbesitzer (wenn er schläft) die Arbeit schneller erledigen kann. Insbesondere ist es möglich, dass der Thread, der das Schloss nehmen will, auf der CPU läuft, auf der der Schlossbesitzer weitermachen soll.

Auf der anderen Seite mit Spinlocks ist die Annahme, dass niemand schläft - dies bedeutet, dass insbesondere beschäftigt warten (d. H. Auf CPU bleiben) nicht blockiert den Besitzer der Sperre. Wenn das Schloss gehalten wird, läuft der Besitzer irgendwo. Aber sagen wir, es ist eingeschlafen. Dies würde bedeuten, dass der wartende Faden die Zeit vergeuden würde, da der Besitzer nicht wieder an die Arbeit gehen kann. Erst nachdem der Scheduler entschieden hat, dass es genug ist, wird es vorweggenommen, aber dann gibt es keine Beziehung zwischen dem Kellner und dem Besitzer. So kann es insbesondere sein, dass der Kellner zurück auf die CPU kommt, um weiter zu warten, während der Schlossbesitzer immer noch nicht die Chance hat zu rennen.

Also wäre es zumindest ein riesiges Leistungsproblem. In der Praxis würde es nur zu Livelocks unter hoher Last führen, bei denen der Kernel keinen Fortschritt machen kann.