scheduling verstaendnisproblem

hallo,

lese gerade linux kernelarchitektur wo auf das scheduling des linux kernels eingegangen wird.

ich habe das kapitel gelesen, soweit alles verstanden, nur irgendwie angenommen das der kernel "immer da ist", quasi immer laeuft, auch wenn gesagt wurde das pro CPU nur ein prozess laufen kann.

gegen ende kommt aber der abschnitt des praeemption, also das der kern auch unterbrochen werden kann. quasi ist der kern auch nur ein prozess? muss ja eigentlich

aber wenn der kernel auch nur ein programm bzw ein process ist, was ja alles ist was aus code besteht, dann faellt er doch auch ins scheduling system?

irgendwie versteh ich das nicht. sagen wir es wird von prozess A nach prozess B geswitched, was ja nur durch den kernel geht. aber der kernel laeuft ja garnicht, da grad prozess A laeuft, und er wird auch nicht laufen, da als naechstes prozess B laeuft. wie wird das dann gemacht?

ich mein der kernel muss doch sowieso immer laufen, sonst geht doch nix, kein prozess kann speicher reservieren, systemaufrufe machen etc, geht doch alles nur uebern kernel.

ich hoffe ihr versteht mein dilemma

bin sehr gespannt wie das nun ist

danke

Psycho

der scheduler ist teil des kernels, soweit richtig.

da nur ein prozess ausgeführt werden kann wird auch der kernel "geschuled".
der scheduler selbst wird dann über einen externen timer durch eine interrupt - routine (isr) aktiviert:

int -> isr -> retten der prozessumgebung (stack etc.) -> scheduler -> nächster prozess ...

genauso werden auch alle anderen externen ereignisse verarbeitet.

genau verstanden habe ich das noch net.

sagen wir in einem programm kommt zb der aufruf

char p[40];

jetzt muss ja der kernel da sein um den speicherplatz bereitzustellen. also muss von diesem prozess zum kernel geswitched werden, was ueber den scheduler laeuft, da aber grade nicht drann ist.
geht das auch ueber nen interrupt? das heisst bei jeder kleinigkeit gibts nen interrupt und der prozess fliegt raus? und von wem kommt der interrupt, wenn nur der prozess grad laeuft?

versteh ich noch net so

Ponto

caps lock schrieb:

genau verstanden habe ich das noch net.

sagen wir in einem programm kommt zb der aufruf

char p[40];

jetzt muss ja der kernel da sein um den speicherplatz bereitzustellen. also muss von diesem prozess zum kernel geswitched werden, was ueber den scheduler laeuft, da aber grade nicht drann ist.
geht das auch ueber nen interrupt? das heisst bei jeder kleinigkeit gibts nen interrupt und der prozess fliegt raus? und von wem kommt der interrupt, wenn nur der prozess grad laeuft?

versteh ich noch net so

Zumindest diese Zeile erfordert sehr selten den Kernel (wenn ein Pagefault stattfindet). Normale Programme switchen zum Kernel, wenn sie einen Syscall ausführen.

linu*x*bie

Lese grad das Buch von Robert Love: Kernel haking
Ne Frage: Also der sheduler berechnet doch die zeitquanten u.a. aus der Stufe der
Interaktivität. Woher weis er den wie ein process interaktiv ist?

Psycho schrieb:

der scheduler ist teil des kernels, soweit richtig.

der scheduler selbst wird dann über einen externen timer durch eine interrupt - routine (isr) aktiviert:

int -> isr -> retten der prozessumgebung (stack etc.) -> scheduler -> nächster prozess ...

genauso werden auch alle anderen externen ereignisse verarbeitet.

Krass, die Frage hat mich auch immer mal interessiert. Jetzt weis ichs

THX

Ringding

Wenn er oft wartet, ist er wahrscheinlich interaktiv. Er kann natürlich auch auf Netzwerk oder Festplatte warten, aber das kann der Kernel wohl auch noch irgendwie herausfinden.

Psycho

Wenn er oft wartet, ist er wahrscheinlich interaktiv. Er kann natürlich auch auf Netzwerk oder Festplatte warten, aber das kann der Kernel wohl auch noch irgendwie herausfinden.

das braucht er nicht rauszufinden... nehmen wir mal an man will etwas von der platte lesen. der user - prozess macht einen syscall der durch einen sogenannten TRAP in den kernel - mode gelangt. hier führt der prozessor jetzt kernel - code aus. was dabei passiert ist folgendes:
der betreffende kernel - code "sagt" der festplatte das sie daten ranschaffen soll. da das aber eine gewisse zeit dauert (positionieren, lesen, schreiben der daten in puffer etc.) wird nach der anforderung der user - prozess blockiert und von scheduler suspendiert. der scheduler lagert einen anderen prozess ein der weiter ausgeführt wird. sobald die platte die daten im puffer stehen hat wird wieder ein interrrupt ausgelöst. die isr sorgt nun dafür das der user - prozess geweckt wird, welcher gerade auf die plattendaten wartet. dieser wird dadurch wieder rechenwillig und wird beim nächsten mal geschedult.

das entscheiden des schedulers welcher prozess gerade dran kommt sieht so aus:
ein prozess mit einer hohen priorität blockiert weil er auf ein ereignis wartet. der scheduler wählt jetzt den nächsten hochprioren prozess aus. sollte es keinen geben kommt einer der niedrigeren ebene dran. um zu verhindern das nur die hochprioren prozesse rechenzeit (sog. verhungern der anderen) bekommen gibt es eine alterrungsfunktion (hochpriore werden runter-, niedrigpriore prozesse raufgesetzt). auf jeder prio - ebene kann jetzt unter den verschiedenen prozessen wieder geschedult werden (round robin, sjf etc.) => den ganzen kram bezeichnet man als preemptives mehrschlangen - feedback - scheduling (ich find das word so geil ).