Danke für die Antworten. Den Vortrag und ein Interview dazu kenne ich, habe ich aber nicht oder nur wenig verstanden. Trotzdem zielte meine Frage genau darauf ab. Wenn ich mich recht erinnere - habe keine Quelle parat - lag laut MD der Nachteil des fine grain darin, daß die Performance bei Einprozessorsystemen nachläßt.
Kann mich täuschen, wie gesagt nur eine Erinnerung, aber hätte ja sein können, daß dem jemand mal auf den Zahn gefühlt hat.
Von Joerg Pernfuss am Mi, 31. Januar 2007 um 22:04 #
Der "klassische" SMP Ansatz ist ein großes Lock für den Kernel (GIANT bei FreeBSD, BKL bei Linux). Rennen alle 4 CPUs im Userland is alles toll, wollen alle 4 was vom Kernel arbeitet nur eine und die anderen 3 blockieren. (FreeBSD 4.x, NetBSD, OpenBSD, Linux 2.irgendwas - ich glaube 2.4)
Der traditionelle Ausweg sieht hier vor das eine große Lock in viele kleine aufzubrechen (FreeBSD 5/6/7, Linux 2.6) und das sauber und ordentlich hinzubekommen ist sehr schwer. Linux hat hier sehr von Arbeit durch SGI profitiert. Ausserdem ist es langwierig. Die vermehrten Lock-Operationen kosten natürlich auf UP Performanz obwohl sie dort eigentlich gar nicht nötig wären (weshalb man normal getrennte SMP/UP Kernel hat).
Matt hatte hingegen eine Vision, eine Kernelarchitektur praktisch ohne jegliches Locking (es gibt an ein paar wenigen Stellen im DFBSD Kernel locks, an diesen Stellen lassen sie sich nicht vermeiden). Und er hatte die Algorithmen dazu im Kopf und wollte das verwirklichen. Da das aber noch nie jemand gemacht hat, war es dem FreeBSD Projekt zu riskant und man hat sich dagegen ausgesprochen. Daraufhin hat Matt DragonFly, den wohl aufwändigsten Proof-of-Concept der IT Geschichte, begonnen.
Es ist ein faszinierendes Konzept, allerdings weiss ich auch nicht, inwieweit er damit jetzt bisher wirklich meßbare Erfolge hinlegen konnte. Ich hatte leider noch keine Zeit mich mit DF zu befassen. Sollte seine Theorie jedoch aufgehen, dürfte er Grundlagenarbeit für die nächsten 20 Jahre IT geleistet haben.
Die Aussage Daraufhin hat Matt DragonFly, den wohl aufwändigsten Proof-of-Concept der IT Geschichte, begonnen. halte ich fuer gewagt. Ich glaube es gab in der IT Geschichte bereits deutlich umfangreichere Proof-Of-Concepts. Und genaugenommen haette er, bevor er das Projekt gegruendet hat, um die Kernelarchitektur komplett umzubauen, zunaechst durch eine Simulationsumgebung die Algorithmen theoretisch auf Herz und Nieren pruefen koennen, die er in die Tat umsetzen will/wollte. Das geht mit deutlich weniger Aufwand, und haette auch die Fachwelt von seinem Vorhaben frueher ueberzeugen koennen.
Kann mich täuschen, wie gesagt nur eine Erinnerung, aber hätte ja sein können, daß dem jemand mal auf den Zahn gefühlt hat.
Der traditionelle Ausweg sieht hier vor das eine große Lock in viele kleine aufzubrechen (FreeBSD 5/6/7, Linux 2.6) und das sauber und ordentlich hinzubekommen ist sehr schwer. Linux hat hier sehr von Arbeit durch SGI profitiert. Ausserdem ist es langwierig. Die vermehrten Lock-Operationen kosten natürlich auf UP Performanz obwohl sie dort eigentlich gar nicht nötig wären (weshalb man normal getrennte SMP/UP Kernel hat).
Matt hatte hingegen eine Vision, eine Kernelarchitektur praktisch ohne jegliches Locking (es gibt an ein paar wenigen Stellen im DFBSD Kernel locks, an diesen Stellen lassen sie sich nicht vermeiden). Und er hatte die Algorithmen dazu im Kopf und wollte das verwirklichen. Da das aber noch nie jemand gemacht hat, war es dem FreeBSD Projekt zu riskant und man hat sich dagegen ausgesprochen.
Daraufhin hat Matt DragonFly, den wohl aufwändigsten Proof-of-Concept der IT Geschichte, begonnen.
Es ist ein faszinierendes Konzept, allerdings weiss ich auch nicht, inwieweit er damit jetzt bisher wirklich meßbare Erfolge hinlegen konnte. Ich hatte leider noch keine Zeit mich mit DF zu befassen. Sollte seine Theorie jedoch aufgehen, dürfte er Grundlagenarbeit für die nächsten 20 Jahre IT geleistet haben.
Und genaugenommen haette er, bevor er das Projekt gegruendet hat, um die Kernelarchitektur komplett umzubauen, zunaechst durch eine Simulationsumgebung die Algorithmen theoretisch auf Herz und Nieren pruefen koennen, die er in die Tat umsetzen will/wollte. Das geht mit deutlich weniger Aufwand, und haette auch die Fachwelt von seinem Vorhaben frueher ueberzeugen koennen.