T
tib
Guest
.
Zuletzt bearbeitet von einem Moderator:
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.
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
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
T
tib
Guest
.
Zuletzt bearbeitet von einem Moderator:
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.
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.htmlEs 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.
-Daemon-
Well-Known Member
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:
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.
Jeff's Replik auf die Antwort von David mündet in der vorsichtigen Beurteilung:
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.
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:
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.
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.
