Arch Linux

Multitasking, Prozesse und der Scheduler

[gelöscht]

In wieweit hat die Anzahl der laufenden Prozesse Einfluss auf die Leistungsfähigkeit des Systems, wenn die (meisten) Prozesse selber laut top keinen cpu Verbrauch haben, und sich auch die Summe auf 0% Verbrauch addiert?

Kontext Wechsel brauchen ja auch immer ein paar Duzend Taktzyklen, und es macht auch Sinn, dass es bei n+1 Prozessen länger dauert, einmal komplett durchzuwandern, als bei n Prozessen.
Hüpft der Scheduler immer linear durch die Prozessliste?
Und was ist mit schlafenden Prozessen?

Werden schlafende Prozesse zyklisch immer mal wieder aufgeweckt, oder werden die vom Scheduler übersprungen, und vom Kernel geweckt?

Also nochmal anders gefragt: Zwei Systemzustände verglichen, in beiden Fällen zeigt top 99% idle an, aber die Anzahl der laufenden Prozesse unterscheidet sich. Hat das System mit der geringeren Anzahl an Prozessen mehr Saft für eine bestimmt Aufgabe? Unterscheiden sich die Latenzen bei Reaktion auf Events?

Möchte ich ein System für eine bestimmte Ressourcenlastige Aufgabe optimieren, macht es Sinn die Anzahl der laufenden Prozesse möglichst klein zu halten, oder reicht es aus den von top gemessenen Verbrauch im Idle Zustand im Auge zu behalten?

[gelöscht]

Linux verwendet in der 2.6-Kernelserie einen O(1) Scheduler. Der Aufwand des Scheduling ist konstant und nicht von der Zahl der Prozesse abhängig.

[gelöscht]

Aha. Jetzt versteh ich was O(1) bedeutet 🙂

Zählen die Kosten der Kontextwechsl zum Aufwand des Schedulers?

Und was gilt für die Zukunft mit CFS? Der müsste ja dann O(n) sein?

GerBra

Ich bin beileibe kein Kernel-Guru

Ab dem 2.6.23 soll ja der CFS den O1 ablösen.
Wie FJO schon sagte, spielten bei diesem die Anzahl der Prozesse schon "keine"
Rolle.

Was versteht du unter resourcenhungrig? Einen Prozeß, der viel und bevorzugt
Rechenzeit braucht oder ein Zusammenspiel mehrerer Prozesse, die eher von einer
niedrigen Load profitieren?

Evtl. wäre (abseits des Kernel-Schedulers) bei dir eher Ansätze in Richtung
nice, Prozeß-Prioriät denkbar.
Oder wieder ein Rückgang auf einen Kernel-Takt von 100Hz, damit der aktuelle
Prozeß einen längeren CPU-Slice bekommt.
Auch das Austesten anderer Scheduler (elevator= am Bootprompt) könnte hilfreich sein.

Ein paar Links hätte ich noch:

http://de.wikipedia.org/wiki/Linux_(Kernel)#Neuerungen_im_Kernel_2.6"
http://www.golem.de/0707/53380.html
http://www.kubieziel.de/computer/halloween-german.html

Und "sehr" alt (aber für's Prinzip immer noch lesenswert):
http://www.oreilly.com/catalog/linuxkernel/chapter/ch10.html

[gelöscht]

Bei der Optimierung ist zunächst auch die Frage sehr wichtig für welchen Einsatzzweck das System vorgesehen ist. Eine Veringerung der Timerfrequenz auf 100 Hz führt beispielsweise zu einer höheren Reaktionszeit des Systems auf äußere Ereignisse. Bei einem Desktop ist jedoch gerade diese Eigenschaft besonders wichtig. Ein Server würde eher von dem dann leicht veringerten Overhead profitieren. Eine änderung der Reaktionszeit im Milisekunden-Bereich spielt hier eher keine Rolle, da die Verzögerungen durch die Netzwerkübertragung in der Regel erheblich höher sind.

[gelöscht]

GerBra schrieb Auch das Austesten anderer Scheduler (elevator= am Bootprompt) könnte hilfreich sein.

Der elevator Parameter beeinflusst nicht den CPU Scheduler, sondern den I/O Scheduler für z.B. Festplatten etc... Soweit ich weiss, kann immer nur ein CPU Scheduler in den Kernel mit einkompiliert werden.

[gelöscht]

Unter ressourceshungrig versteh ich hier einfach rechenintensive Aufgaben.

Eigentlich geht mir hier hauptsächlich um das Verständnis von Multitasking unter Linux;

Die konkrete Anwendung wegen derer ich anfing, darüber nachzudenken ist Musikproduktion am PC.

Ich möchte möglichst wenig Taktzyklen verschwenden, um möglichst viel Synths und Effekte in Echtzeit berechnen zu lassen.

Dafür sind niedrige Timerfrequenzen schlecht geeignet, da das MIDI Timing darunter leidet.

Die Grundfrage ist einfach, ob es Sinn macht, auf praktische daemons und andere hilfreiche Programme im Hintergrund zu verzichten, auch wenn top keinen cpu Verbrauch meldet; Soweit ich weiß werden die Kosten der Kontext Wechsel nicht in top angezeigt.

Wenn ein Fokuswechsel der CPU zwischen Prozessen eine endliche lange Zeit dauert, müßte das ja bedeuten, daß mehr aktive Prozesse zwischen denen kostant gewechselt werden muß, das System ausbremsen, selbst wenn sie nicht tun?

Ich schätze, FJO hat die Frage mit dem Hinweis auf O(1) für den alten Scheduler beantwortet?

Danke auch für die Links GerBra, der letzte ist recht interessant