Freebsd 4.x, 5.x: was macht SMP

H

hell_bird

Active Member
hi,

Es gibt eine Frage, die mich die ganze zeit in der ich mir überlege/versuche mal FreeBSD auf meine Platte zu bekommen stelle. Anscheinend hat es von der version 4.x zu 5.x einige bedeutende änderungen gegeben, die jeweils ihre verfechter haben. ich meine wenn sich sogar dragonflybsd abspaltet kann es sich ja nicht um kleinigkeiten handeln. Ausschlaggebend war, wie ich gelesen habe, die einführung von SMP. Dabei wird von fine-grained locking , BigLock und Giant-Lock gesprochen...
Ich nehme einfach mal an, dass es sich dabei um Threadsynchronisation handelt, aber was ist der unterschied? und wieso soll SMP schlecht sein? Ist Freebsd 5.x langsamer oder ist die Streitfrage hier eher was das bessere Design ist.
 
SMP kann FreeBSD seit 3.0, und zwar mit BigLock (BGL - Big Giant Lock, Giant Lock, alles das gleiche). Seit 5.x versucht man wieder loszukommen von BGL, indem man auf fine-grained locking umsteigt, was eine heidenarbeit ist.
Es geht hier hauptsächlich um synchronisation von Kernel-threads, DFBSD will das anders regeln als FreeBSD, wie genau weiss ich auch nicht. Die Streitfrage ist wohl hauptsächlich das Design, was im Endeffekt besser, schneller, wartbarer, etc. ist, darauf dürfen wir gespannt sein :)
 
hell_bird, wenn du Zugang zu einer guten Bibliothek hast, kannst du dir einmal <<Understanding the Linux Kernel, 2nd Edition>> ausleihen, dort ist im Kapitel über Synchronisierungsmaßnahmen eben beschrieben, wie diese funktionieren.

Allgemein kann man sagen, daß versucht wird die Parallelität(engl. concurrency) bei SMP zu erhöhen. Bei einem gewöhnlichen Lock nun, wird ein Zähler dekrementiert, wobei der Startwert normalerweise 1 ist, was heißt, nur ein Kernel-Mode-Path kann auf die geschützte Datenstruktur zugreifen. Wenn er unter 0 geht, so wartet der Kernel-Mode-Path, der den Lock besetzen will, bis er wieder bei 1 ist, was dann geschieht, wenn der erste Kernel-Mode-Path wieder den Lock freigibt. Wenn nun ein Kernel-Mode-Path auf den Lock wartet führt er nur noops aus, also nichts, das heißt er verbrät Zeit, die Parallelität geht flöten. Ein Big-Reader Lock nun verbessert manchmal das Laufzeitverhalten dadurch, daß er zwei Variablen einführt, eine für die, die eine bestimmte geschützte Datenstruktur nur lesen wollen, wobei diese ein Array ist, für jede Cpu ein Eintrag, und eine für die, die etwas an ihr verändern wollen. Die letztere ist global, es gibt nur eine, egal wieviele Processoren. Dies geschieht im Gegensatz zu den normalen Read/Write-Locks(dies sind keine gewöhnlichen Locks, es wird in diesen zwischen Kernel-Mode-Paths unterschieden, die lesen oder schreiben wollen. Hier gilt, es kann unbegrenzt viele Reader geben, aber nur einen Writer, und diesen nur dann, wenn es keine Reader gibt) , wo es nur eine Variable gibt, die beides regelt. Dadurch wird der Cache besser genutzt, denn wenn ein Kernel-Mode-Path lesen will, so muß er nur eine Variable im Array verändern, die stört die anderen CPUs nicht, sie müssen keinen Cache-Flush durchführen, weil sie den Read-Eintrag nicht lesen müssen, wenn sie selber nur lesen wollen, also wird dieser Eintrag praktisch bei Leseversuchen nicht ungültig. Nur beim Write-Fall ist es schwieriger, hier muß der Kernel-Mode-Path den ganzen Array auslesen, also die Daten aus dem Cache der anderen Cpus erhalten. Da aber meistens Kernel-Mode-Path nur lesen wollen, ist das kein so großes Problem. Und trotz dieser potentiellen Vorteile wird in Linux 2.4 dieser Big-Reader Lock nur einmal auf x86 benutzt, naja.

Ich weiß nicht wie es bei *BSD aussieht, aber ich hoffe ich habe mich verständlich ausgedrückt.
 
aha vielen dank!

@mama: Das was du als gewöhnlichen Lock bezeichnet hast nennt sich auch mutex oder? ist das der fine-grained lock? naja wäre etwas zu einfach dafür...
 
Ja das nennt man auch mutex, ich glaube, daß ist nicht der fine-grained Lock, ich kenne mich aber mit freeBSD-Kernelentwicklung nicht so aus, ich wollte einfach nur einmal einen Einblick in die Problematik der Synchronisierung geben, weiß aber nur wie es in Linux gelöst wird, nämlich mit gewöhnlichen Locks und Read/Write-Locks, und SMP bei Linux ist, ich kann leider nicht mit persönlicher Erfahrung dienen, ganz gut, soweit ich gehört habe.
 
Ich bin mir nicht 100% sicher, aber:
BGL ist _ein_ großer gigantischer Mutex für den gesamten Kernel.
Fine-grained beudeutet unterschiedliche Mutexen für unterschiedliche Dinge.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben