Scheduler

ouTi

BSD sucker
Der Scheduler SCHED_ULE hat momentan keinen aktiven Maintainer. Durch Änderungen am Kernel etc. ist dieser momentan nicht funktional (in CURRENT).

Nachdem SCHED_ULE in 5.2 als default gesetzt wurde sind viele Probleme aufgetaucht. Da diese aber nicht trivial zu lösen sind und es keine Maintainer gibt wurde wieder zurück auf SCHED_4BSD gewechselt. SCHED_$BSD enthält aber mittlerweile auch viele Änderungen und Neuerungen, die Einzug in SCHED_ULE hielten und wurde dadruch ebenfalls verbessert.
 

asg

push it, don´t hype
SCHED_ULE ist defakto tot.
Siehe vierter Absatz: http://www.grunix.de/2006-11-20/180/freebsd-70-ein-ausblick/

Viele Teilbereiche aus ULE sind in 4BSD eingeflossen. Frage nun nicht welche, da sollte aber eine entsprechende ML Auskunft darüber geben.

Als das genannte Buch geschrieben wurde, war man noch der Auffassung das es mit ULE noch hinhauen wird. Naja, da war man ja auch noch frohgemutes was die 5.x angeht (die ja wohl nicht wirklich ein Aushängeschild für FBSD war - aber gut, wenn man das komplette System umstrickt...).

Wie dem auch sei, SCHED_CORE ist das neuste Kind und soll, evtl. möglicherweise, wahrscheinlich..., in 7.0 kommen.
Achja, hier unter CURRENT rennt CORE ohne Probleme, anders sah es damals mit ULE aus, welches immer langsamer war als 4BSD.
manpage zu CORE:
http://www.freebsd.org/cgi/man.cgi?...ktion=0&manpath=FreeBSD+7-current&format=html
 

Daniel Seuffert

Well-Known Member
ULE ist tot, es lebe ULE 2.0 ;) Wie wir auf -current erfahren habe hat Jeff Roberson nach einer gewissen Auszeit wieder Motivation und Inspiration gefunden die ausstehenden Probleme anzugehen und hat auch schon fleissig dazu committed. Erklärungen dazu findet man in seinen logs und hier: http://jeffr-tech.livejournal.com/3729.html

Es scheint also so, daß es da weitergeht. David Xu, der ja an sched_core arbeitet, hat dazu einige Vorschläge/Anmerkungen gemacht. Mal sehen wie sich das weiterentwickelt. Offensichtlich haben wir eine ideale Situation: 2 teilweise konkurrierende Ansätze werden parallel weiterverfolgt und irgendwann wird es eine conclusio geben imho. Ich hoffe und erwarte das Beste in dieser Hinsicht.
 

Daniel Seuffert

Well-Known Member
Na ganz simpel so, wie es David Xu ausführlich in 2 replies beschrieben hat: Er (David) ist der Meinung, daß es wichtiger/richtiger sei, an einem CPU dispatcher zu arbeiten. Falls sich seine Einschätzung bestätigen würde, dann würde David die Arbeit an sched_core einstellen und sich darauf konzentrieren. Jeff teilt seine Einstellungen nur zum Teil, gibt aber keine abschliessende Beurteilung dazu ab.

Jeff's Replik auf die Antwort von David mündet in der vorsichtigen Beurteilung:

I don't know how practical it is to try to seperate the SMP scheduling
from the fairness and interactivity scheduling. In ULE they are somewhat
tightly integrated. Although I think it's good to experiment. Perhaps
you could try forking the 4BSD scheduler and add these SMP features if you
like.

Das Thema ist zu komplex und zu weitreichend in seinen Folgen, als das jemand es wagt frank und frei irgendwelche definitiven Stellungnahmen abzugeben. Und da beide Hauptbeteiligten (Jeff und David) in diesem Punkt übereinstimmen bleibt nur ein Schluss: Es ist sind Experimente jeweils mit offenem Ausgang. Es mag sein, daß sich ein Konzept durchsetzt oder eine Mischung aus beiden (ULE 2.0 mit neuem CPU dispatcher von David) oder es kommt dazu, daß beides irgendwann durch etwas vollkommen anderes ersetzt/ergänzt wird. Das etwas Neues kommen muss ist klar in Zeiten von CPUs mit 128 cores, aber was es am Ende sein wird ist noch offen.
 

Kamikaze

Warrior of Sunlight
Klingt ja ganz spannend. Es wäre schön wenn sich das tatsächlich auf Evolution durch konkurrierende Konzepte hinausläuft.
 

Daniel Seuffert

Well-Known Member
Update dazu: Jeff hat zwischenzeitlich wieder fleissig committed und etliche mails gingen zwischen im und David hin und her. Jeff holt sich auf Hinweis mittlerweile Anregungen bei Solaris. Bemerkenswert sind folgende zwei Aussagen von Jeff imho:

I just fixed a regression in the load balancer. On my 8way opteron ULE is
now 22% faster than 4BSD for select-key.smack with 32 threads. This is
for both KSE and libthr. libthr is of course significantly faster
overall. I believe I can improve this even more by borrowing some tricks
from solaris.

An initial implementation of what I felt were the most significant parts
of the solaris algorithm pushed it up to 50% faster than 4BSD. I probably
won't have this ready to commit for a few days however.

Das hört sich momentan alles positiv an und eine Menge Leute liefern input bzw. testen, es scheint das tut dem Prozess sehr gut. Zumindest ist wesentlich mehr Bewegung in die Sache gekommen. Warten wir ab, was sich in den nächsten Monaten daraus ergibt.
 
Oben