Weil auf freebsd-{performance,current,stable,...}@lists.freebsd.org letztens die Diskussion um einen 200-Zeilen-Patch für Linux, der Prozesse für den Scheduler nach Terminals gruppiert, hochgekocht ist, habe ich mich auch mal wieder damit beschäftigt, wie schlecht doch der aktuelle Standard-Scheduler SCHED_ULE (ein Wortspiel, wie dem geneigten Leser schnell auffällt) funktioniert. Und das nicht nur auf einem Desktop-System, sondern generell.
Eigentlich tut er seine Arbeit so schlecht, dass man es tunlichst vermeiden sollte, ihn zu verwenden: Denn eine gerechte Aufteilung der Rechenzeit auf lauffähige Prozesse ist nicht sein Ding. Er tut es eher: zufällig? unnachvollziehbar? eigensinnig? Es ist schwer, ein Wort zu finden, das den Zustand beschreibt.
Jedenfalls haben die „normalen“ Unix-Prioritäten, die man mittels nice() oder setpriority() setzen kann, offensichtlich kaum einen Einfluss, und irgendwie erhalten rechenzeitintensive Prozesse viel zu viel Zeit im Gegensatz zu interaktiven Prozessen, die wenig tun, aber schnell bedient werden wollen – z.B., weil sonst der Mauszeiger des Benutzers ruckelt.
Das äußert sich dann so, dass man seine Maschine kaum noch benutzen kann, wenn man nebenbei Code kompiliert. Eigentlich ein Unding.
Daher benutze ich also wieder den alten BSD-Scheduler SCHED_4BSD, und bin zufrieden. Eigentlich schade, weil SCHED_ULE auch mit der CPU-Topologie umgehen kann, was bei Hyperthreading-Prozessoren ein großer Vorteil ist. Habe ich aber nicht, insofern tut es SCHED_4BSD auch.