Scheduler in FreeBSD

[Kamikaze]

Bin ich der einzige dem sched_ule auf die nerven geht? Die Idee Rechenintensiven, langlaufenden Prozessen höhere Priorität einzuräumen ist mir nicht ganz knusper.

Bei einem buildworld oder anderen großen Compilerorgien wird X dann auch mal so träge, dass selbst der Mauscursor ruckelt. An videos schauen ist schon gar nicht zu denken.

Mir scheint eher, dass all die kleinen Prozesse, die nicht so viel Rechenzeit brauchen alles bekommen sollten und die großen, rechenintensiven Prozesse nur den Rest. Dann könnte man auch mal ungestört etwas auf Youtube schmökern, während im Hintergrund der Compiler von der Restkapazität läuft. Ganz nach dem Motto schnell reagieren statt einfach nur schnell rechnen.

 

[peterle]

Man kann dann aber auch deutlich länger Videos bei youtube schauen, da der Hintergrundprozess so elend lange laufen wird ...
Wie mans regelt, regelt man es vermutlich falsch oder wie ist das bei anderen und früher gewesen?

 

[Crest]

ULE funktioniert für mich wunderbar. Bei Compileorgien bietet es allerdings an nice bzw. rtprio zu benutzen.

 

[Kamikaze]

Man kann dann aber auch deutlich länger Videos bei youtube schauen, da der Hintergrundprozess so elend lange laufen wird ...
Wie mans regelt, regelt man es vermutlich falsch oder wie ist das bei anderen und früher gewesen?

Gab es früher nicht mal die Regel, dass interaktive Prozesse höhere Priorität haben?

 

[Yamagi]

Bei Scheduling gilt grundsätzlich, dass man es nur falsch machen kann. Die wirklich für alle Workloads funktionierende Lösung gibt es nicht. Daher schimpfen die Linuxer auf ihren CFS, wir auf unseren ULE, die Windowsianer auf ihre System, etc... ULE hat als Schwäche hauptsächlich den Fall, dass mehr wirklich Leistung ziehende Prozesse als CPUs vorhanden sind. Besonders schlimm wird es, wenn viele dieser Prozesse auch so kurzlebig sind, während einige lange laufen. Klassischer Fall ist z.B. "make -j8" auf einem Quadcore, während gleichzeitig in X.org gearbeitet wird. Aber hier gibt es Abhilfe:

1. Den Preempt-Threshold hochsetzen. Steigert die Interaktivität. "224" ist ein Wert, der auf den Mailinglisten oft als optimal für Desktops genannt wird, aber an und an liest man auch andere. Ich bin mit 224 sehr zufrieden.

sysctl kern.sched.preempt_thresh=224

2. Gerade dickeren SMP-Maschinen helfen einige Änderungen an ULE aus 10-CURRENT sehr. Leider haben sie es nicht ins 9.1 geschafft und sind bisher auch nur teilweise im 9-STABLE. Die Revisionen zum selbermergen sind: r240839, r241248, r241249, r241250, r239196, r239585, r240513, r242014, r242356, r242736, r242852, r243069

3. 4BSD nehmen. Ist ULE tendentiell überlegen, wenn man viele leistungsfressende Langläufer hat. Z.B. beim wissenschaftlichen Rechnen. In allen anderen Fällen ULE eher unterlegen, generell aber interaktiver.

 

[Kamikaze]

Um ehrlich zu sein habe ich noch nie zuvor Kritik an ULE gehört. Ich probiere das mit dem preempt_thresh mal aus!

 

[s-tlk]

Es gibt wirklich unzaehlige 4BSD vs. ULE Scheduler Threads, die aber alle gemein haben, das es einfach keine eierlegende Wollmilchsau gibt. Erst kuerzlich war wieder was auf @Stable/Current.

Ich hatte bisher nur mal auf meinem Laptop sowas aehnliches gehabt wie du beschreibst und da hat das Hochsetzen der preemptiv threshold sehr geholfen.
Auf dem Desktop hatte ich sowas noch nie erlebt. Ich vermute immer noch, das es eigentlich am HT auf dem Laptop liegt.

 

[bost]

Mein kleiner Mail-Vserver bei Hetzner hatte arge Probleme mit ULE.
Seit 4BSD ist die Shell-Interaktivität bei Last (kompilieren) erheblich besser geworden.
Außerdem habe ich jetzt keine zufälligen Verbindungsabbrüche mehr.

 

[lme]

Selbst mit dem preemptive threshold laufen Videos nicht ganz rund, wenn ich im Hintergrund mit -j4 baue (auf nem Core2Duo).
Einfache und wirkungsvolle Abhilfe:

renice -20 -u lars

Dann bauts im Hintergrund fleißig und vorn kann ich HD Videos schauen.