FreeBSD: der neue Scheduler — WIP

Jeff Roberson, der sich schon für SCHED_ULE verantwortlich zeigte in FreeBSD 7, gibt keine Ruhe. Der erste Schlag war die Etablierung dieses neuen Schedulers, der auch Linux gekonnt in die Schranken verwies bzw. immer noch verweist, dann begann das Finetuning und inzwischen werden auch neue Technologien implementiert (8 current). Nokia, die FreeBSD einsetzen, unterstützen Jeff bei seinem Vorhaben. Laut seiner Antwort auf meine Mail wird wahrscheinlich ein Teil dieser Technologien (neue API und Scheduling policies, z.B. cpu topology load balancing) auch in RELENG_7, respektive 7.1R zu sehen sein. Voraussetzung aber ist eine Menge mehr Erfahrung mit diesen Technologien, damit ein MFC gerechtfertigt ist.

Kris Kennaway konnte sich schon in einem vorab-Benchmark mittels Postgres von den Qualitäten überzeugen. Die grüne Linie ist der Scheduler unter FreeBSD 7.0R, jener der auch Linux schlug und schlägt 😉

4 Antworten zu “FreeBSD: der neue Scheduler — WIP”

  1. blub sagt:

    Ich will Kris Kennaway ja nichts unterstellen, aber ich habe zu den Benchmarks ein paar Fragen. Bitte nicht übel nehmen, ich hoffe auf eine vernünftige Diskussion ohne Flames!

    Ich beziehe mich hier auf die «alten» Benchmarks, also die, die in Kris’s PDF zu finden sind.

    1.) Ist die FreeBSD Performance out-of-the-box? (plus aktiviertem ULE Scheduler), d.h ohne jegliches Tuning?

    2.) Wurde Linux irgendwie getuned? (wo gibts die Kernelconfig?)

    3.) Ich habe damals, als die ersten Benchmarks veröffentlich wurden, selber nachgemessen. Allerdings nur auf einem Quad-Core System und konnte den Einbruch von Linux bestätigen, der dann ein paar Monate später gefixt wurde. Allerdings gab es zwischen den einzelnen Distributionen schon deutliche Unterschiede. Debian war z.b locker 10% schneller als Fedora (mit dem jeweiligen Standardkernel der Distribution), vermutlich lässt sich duch weiteres .config Tuning noch das ein oder andere Prozent rausholen.

    4.) Der Fedorakernel hat standardmäßig ein paar Debuggingoptionen eingeschaltet, insbesondere meine ich:

    CONFIG_SCHEDSTATS=y
    CONFIG_TIMER_STATS=y
    CONFIG_DEBUG_SPINLOCK_SLEEP=y
    CONFIG_DEBUG_HIGHMEM=y
    CONFIG_DEBUG_LIST=y
    CONFIG_HIGHPTE=y

    Diese sollten alle auf ‘n’ gesetzt werden.

    5.) Ich glaube die default-hz sind bei Fedora 250, wie sieht das bei FreeBSD aus? (Das macht auch ein paar Prozent Unterschied).

    6.) MySQL unter Linux hat meines erachtens einen Bug, es werden sehr viele Systemcalls ausgelöst, die alle Fehlschlagen, siehe:

    sched_setscheduler(20760, SCHED_OTHER, { 6 }) = –1 EINVAL (Invalid argument)

    Im MySQL-Code:
    #if (defined(__BSD__) || defined(_BSDI_VERSION)) &&
    !defined(HAVE_mit_thread)
    #define SCHED_POLICY SCHED_RR
    #else
    #define SCHED_POLICY SCHED_OTHER
    #endif

    #ifndef my_pthread_setprio
    void my_pthread_setprio(pthread_t thread_id,int prior)
    {
    #ifdef HAVE_PTHREAD_SETSCHEDPARAM
    struct sched_param tmp_sched_param;
    bzero((char*) &tmp_sched_param,sizeof(tmp_sched_param));
    tmp_sched_param.sched_priority=prior;
    VOID(pthread_setschedparam(thread_id,SCHED_POLICY,&tmp_sched_param));
    #endif
    }
    #endif

    Wenn ich den Code auskommentiere gibts auch wieder eine ~5% Leistungssteigerung (wiegesagt, mit 4 Cores, bei 8 oder 16 Cores entsprechend mehr).

    Zusammengefasst: Wie gesagt möchte ich Kris bei seinen Benchmarks nichts unterstellen. Es ist auch gut möglich, dass FreeBSD tatsächlich schneller als Linux ist, dass möchte garnicht von der Hand weisen. Allerdings ist mir ein 15% Unterschied zu gering, als das ich FreeBSD sofort zum Sieger erklären würde. Ich hoffe meine obigen Punkte haben das halbwegs plausibel dargestellt.

    Viele Grüße

  2. Oliver sagt:

    zu 1) Das «Tuning» war im Prinzip die Aktivierung von SCHED_ULE anstatt SCHED_4BSD.

    zu 2) Linux wurde zuvor von Jeff Roberson schon früh mit Patches zu CFS versorgt (und auch ohne, mit dem alten Scheduler) und das ganze wurde von fähigen Linux-Usern auf seinem Blog kritisch begleitet. U.a. konnte man bei Linux ob der ersten Benchmarks damals einen herben Bug glaube ich in der libc ausmachen.

    zu 3) siehe Punkt 2

    zu 4) die Benches gingen ein Weile, dessen war man sich bewußt

    zu 5) 1000

    zu 6) unter FreeBSD hat MySql auch einige herbe Macken, es läuft per se eigentlich immer besser unter Linux — das sollte auch allgemein bekannt sein. Mit diesem Hintergrund sind die gezeigten Werte auch für FreeBSD überragend.

    Last not least, ohne flame bait zu liefern, BSD betreibt nie extremes Tuning (überhaupt keines innerhalb eines Releases), insofern sieht man da Dinge die alltagstauglich sind. Obiger *vorab*-Benchmark mit Postgres ist zudem ein Test mit diversen Einstellungen. Bei BSD gibt es *einen* Kernel, den *jeder* nachher auf seinem System besitzt. Insofern hast du recht, möchte man einen echten Vergleich mit Linux machen, so müßte man alle großen Distros nehmen, dazu die jeweiligen teils übel gepatchten Kernel plus CFS oder auch ohne (wobei zumindest letzteres desöfteren Anwendung fand bei Jeff). Das man Red Hat nimmt hat wohl damit zu tun, das diese auch mehr Einsatz finden als nur auf dem Desktop. Das zudem ein Kernel der gestern noch gut war morgen schlechter sein kann beim nächsten Release bzw. vice versa liegt in der Natur der Sache bei der Linux Entwicklung. Bei BSD gibts nun einmal beim Release einen Kernel und an diesem ändert sich nichts bis zum nächsten Release. Insofern kann Linux morgen noch schlechter sein oder noch besser, das weiß man nie so recht.

    Übrigens auch hier ähnliches bei einem BIND Benchmark. Gründe für mögliche gewaltige Einbrüche bei Linux sind ebenso erwähnt. Für den Rest kann man Kris anschreiben man bekommt dort zu allem Auskunft.

  3. blub sagt:

    Danke für deine Antwort Oliver,

    Es kann gut sein das MySQL unter Linux immer besser läuft als unter FreeBSD (ist ja auch irgendwie logisch, ich denke die Hauptentwicklung findet unter Linux statt und andere Unixsysteme kommen später, obwohl sich das vielleicht bald ändert und das Hauptaugenmerk auf Solaris gerichtet wird 😉

    Ich gebe dir schon recht was die Leistung der jeweiligen Linuxkernel angeht. Die Entwicklung geht nunmal sehr schnell voran und es ist nicht abzusehen wo das aufhört. Wenn man ab und zu lwn.net ließt bekommt man eher den Eindruck das es immer schneller wird :)

    Es werden trotzdem regelmäßig Regressiontests durchgeführt (eigentlich gegen jeden neuen Snapshot).

    Siehe z.b:
    http://test.kernel.org/

    oder

    http://kernel-perf.source.….rge.net/

    Vielleicht sollte man in Zukunft überlegen, MySQL/Postgres Sysbench und BIND mit in die Liste aufzunehmen.

    Wenn ich das richtig verstanden habe, arbeitet im FreeeBSD-Lager auch jemand an einem automatischen Performance-Tracker, so unterschiedlich ist das also nicht.

    Zu den BIND Benchmarks.. Es wäre schön, wenn die ISC den Benchmark mit den aktuellsten Versionen der jeweiligen Systeme wiederholen könnte.

    Und bitte nimm es mir nicht übel, wenn ich den Benchmarks von Kris etwas kritisch gegenüber stehe. Er vertritt immerhin das FreeBSD-Project, ist also nicht 100% objektiv (was nicht heißen soll, dass die Benchmarks getürkt sind!) Mir ist ein unabhängiger Benchmark im Endeffekt doch lieber.

    Viele Grüße

  4. Oliver sagt:

    >Es werden trotzdem regelmäßig Regressiontests durchgeführt (eigentlich gegen jeden neuen Snapshot).

    Das ist klar, ich verwende heute noch Linux bzw. verwendete es primär seit Mitte der 90er bis zu FreeBSD 5. Aber anständige Distros die auf Qualität setzen verwenden nicht ohne Grund ältere Kernel. Denn diese Testzeit die man für die heutigen Release-Kernel (aka Developer Kernel) ansetzt ist keine und bei der Fülle von Änderungen auch lächerlich. Die frühere Praxis eines Developer-Kernels war auf jeden Fall besser für die Qualität.

    >Wenn man ab und zu lwn.net ließt bekommt man eher den Eindruck das es immer schneller wird

    Habe ich trotz des extensiven Charakters ebenso im Abo und kenne auch die ewigen Diskussionen Fehlern ebenso Aufmerksamkeit zu schenken.

    >Er vertritt immerhin das FreeBSD-Project, ist also nicht 100% objektiv

    Das ist korrekt, FreeBSD hätte jedoch auch einen Ruf zu verlieren, da das Gros des Einsatzgebietes Server bei Nokia, Yahoo, Juniper etc. sind. Der Desktop macht nur einen kleinen Teil aus, profitiert jedoch auch davon. Wie gesagt fragen kostet nichts und Kris gibt sicherlich bezüglich jeden Details Auskunft, zudem kann man das Gros davon auch nachlesen auf den MLs.

RSS-Feed abonnieren