Wo sind meine 8 cores hin?

dettus

Bicycle User
Hallihallo.


Auf der Arbeit habe ich einen neuen Rechner zum Einrichten bekommen. WIRKLICH brauchen tun wir den erst ab naechstem Jahr. Also... was macht der gute Hacker? Richtig. Erstmal OpenBSD drauf.
Superschoene Kiste: Ich war sowas von am feiern als der beim booten die cpu48 gezeigt hatte und da noch mehr kamen... :)


Aber warum ist bei 64 schon schluss? Laut Datenblatt und lscpu hat der 72?
 

Yamagi

Possessed With Psi Powers
Teammitglied
Zumindest bis FreeBSD 13 mit dem Lockless-Kernel (dummer Marketingname) kommt. :p Aber im Ernst. Der klassische BSD-Kernel implementierte die CPU-Zuordnung bei SMP-Systemen über eine Bitmaske und wenn die nur 64 Bit lang ist, gibt es eben nur 64 CPUs. Keine Ahnung, ob OpenBSD das wirklich noch so macht, es riecht aber etwas danach.
 

turrican

Well-Known Member
Hast du den bsd.mp Kernel am Laufen (klar, 64 Kerne erkennt er ja)?

was sagt sysctl:
hw.ncpu
hw.ncpufound
hw.ncpuonline
 

turrican

Well-Known Member
Das ist die simpelste Implementierung und sehr speicherschonend.
Interessant - also wars wg "Speicherplatz sparen" oder machen es Vorgänge innnerhalb OpenBSD notwendig, schnell einzelne CPUs ausmaskieren zu können?

OpenBSD forkte ja Mitte der 90er von NetBSD - war das in Net dann auch so implementiert?

A propos mitte der 90er- was hatte man da an RAM in nem i386 Maschinchen: 2, 4, 6, 8, 16 MB... machte diese Einsparung da trotzdem wirklich so den Unterschied zu nem gespeicherten Integer-Wert?
 

Andy_m4

Well-Known Member
Das mit dem "Speicherplatz sparen" ist natürlich so gesehen kompletter Unfug (also so, wie es hier offenbar verstanden wurde). Kann man sich auch leicht selbst überlegen. Wenn es nur um die Anzahl der CPUs ginge, würden ja bei dem Maximalwert von 64 sogar 5 Bits genügen. Selbst wenn man unterstellt, das die kleinste adressierbare Einheit 1 Byte (also 8 Bit) wären, wäre das immer noch deutlich kleiner als eine Bitmaske mit 64 einzelnen Bits was zusammengerechnet ganze 8 Bytes RAM schluckt.

Nein. Bei Bitmasken geht es (wie hier auch schon angedeutet) darum Einzelwerte darstellen zu können. Bits sind hier Wahrheitswerte. 1 für verfügbar. 0 für nicht verfügbar.

Ohne jetzt die genauen Details zu kennen und auch nur als veranschaulichende Beschreibung:
In einem Mehrprozessorsystem geht es ja darum Prozesse oder Threads auf CPUs zu verteilen. Nun kann man einfach hingehen und sagen: Ich mach eine Bitmaske. Und bereits belegte CPUs bekommen bei mir eine 0 und freie CPUs eine 1. Das halte ich in einer Bitmaske fest. Wenn ich eine freie CPU suche lege ich darüber auch noch MAXCPUS damit ich nicht freie CPUs rauspicke, die gar nicht da sind.

Und warum als Bitmaske? Die Gründe wurden richtigerweise schon genannt. Für Wahrheitswerte nur ein Bit zu nehmen ist natürlich die speicher-sparsamste Methode die man nehmen kann. Und Bitmasken-Operationen sind sehr effizient. Wurde ja auch schon gesagt. Ich hoffe nun ist klarer geworden, was damit gemeint ist.
 

Yamagi

Possessed With Psi Powers
Teammitglied
Das ist lange her und war teilweise noch vor meiner Zeit: Auch wenn es schon seit den 1960er SMP-Maschinen gab, kamen SMP-Maschinen für die Masse erst in den 90er Jahren auf. Entsprechend konnte der Unix-Kernel - sofern man denn bei der Fragmentierung nach etwa 1980 von so etwas sprechen kann - kein SMP. In den SysV-Zweig wurden Anfang der 90er einige kommerzielle Derivate SMP-fähig, vor allem SunOS 5 aka Solaris. In der BSD-Welt stammen meines Wissens alle SMP-Kernel von FreeBSD ab. Dazu kommt, dass es lange Zeit keine standardisierte Thread-Bibliothek gab, pthreads setzten sich erst Anfang des Jahrtausends durch. Vorher nutzt man proprietäre Implementierungen, wie beispielsweise LinuxThreads oder unter FreeBSD libc_r.

FreeBSDs SMP-Kernel wurde ab Mitte der 90er in einem eigenen Branch entwickelt, der irgendwann in 3-CURRENT gemerged (Mergen war mit CVS ein Hampelkram zum Quadrat) und 1998 mit FreeBSD 3.0 veröffentlicht wurde. Es war eine aus heutiger Sicht recht primitive Implementierungen, mit einem globalen Kernellock (der berüchtigte GIANT) und an einigen ausgewählten Stellen wie der Prozessverwaltung ich meine 4 granularer Locks. Damit konnten Userland-Prozesse parallel laufen und Threads implementieren, der Kernel lief aber weiterhin singlethreaded. Das klingt schlimmer als es war, für die damaligen Maschinen war es ausreichend und konkurrenzfähig zu Linux. Daher kommt wahrscheinlich auch die Bitmaske, es war eine simple Lösung für das Problem.

Bald wurden Computer aber schneller, vor allem gab es mehr Sockel. Mit bis zu 8 CPUs im Massenmarkt mit der Pentium 3 Generation. Und pthreads setzten sich durch. Damit funktionierte dieser simple Ansatz nicht mehr. BSDi - vor allem durch BSD-Klage bekannt - nahm FreeBSDs SMP, mergte es in ihr eigenes 4.4BSD-Derivat BSD/OS und baute den Kernel teilweise auf Fine Grained Locking um. Nachdem BSDi pleite gegangen war, spendeten sie den Code und FreeBSD mergte ihn in das eigene System zurück. Das bildete die Grundlage für den radikalen Umbaue des Kernels im Rahmen von SMPng, was nach schmerzhaften Jahren als FreeBSD 5 veröffentlicht wurde. FreeBSD 6 stabilisierte es und mit FreeBSD 7 war es dann voll da. Das bedeutete aber auch, dass die BSD-Kernel stark voneinander zu divergieren begannen. Und FreeBSD 13 wird sich durch den Wechsel von Locks auf Epochs in den meisten bis allen performancekritischen Pfaden noch mal weiter von den anderen BSDs entfernen.

FreeBSD behielt die Bitmaske noch lange bei, ich meine mich zu erinnern, dass erst FreeBSD 8 sie durch die cpuset() API ersetzte. Wobei auch cpuset() unten drunter mit Bitmasken arbeitet, sie sind halt nur nicht statisch alokiert. NetBSD und OpenBSD veröffentlichten die ersten SMP-Kernel erst um und bei 2004, sie übernahmen die Implementierung im Großen und Ganzen aus FreeBSD (also vor SMPng), wodurch sie auch die Bitmaske erbten.
 

pit234a

Well-Known Member
FreeBSD 5 veröffentlicht wurde. FreeBSD 6 stabilisierte es und mit FreeBSD 7 war es dann voll da. Das bedeutete aber auch, dass die BSD-Kernel stark voneinander zu divergieren begannen.
Es war eine aus heutiger Sicht recht primitive Implementierungen, mit einem globalen Kernellock (der berüchtigte GIANT) und an einigen ausgewählten Stellen wie der Prozessverwaltung ich meine 4 granularer Locks. Damit konnten Userland-Prozesse parallel laufen und Threads implementieren, der Kernel lief aber weiterhin singlethreaded.
War das nicht so in etwa die Zeit und der Grund für das lostreten von DragonFly?
Ich vergesse regelmäßig mehr, als ich mir behalten kann.
Aber es wäre interessant, die Verwicklungen von DragonFly auch mal zu beleuchten. Kennt sich da einer aus?

Wie war das damals und was haben die DragonFly-Leute anders gesehen und anders gemacht? Was ist daraus geworden? und wieviel davon fließt nun wieder zurück? Hat das Einfluss auch FreeBSD_13? oder machen die wieder was ganz Neues?
 

Yamagi

Possessed With Psi Powers
Teammitglied
War das nicht so in etwa die Zeit und der Grund für das lostreten von DragonFly?
Ich vergesse regelmäßig mehr, als ich mir behalten kann.
Ja. Matt Dillon war mit einigen Entscheidungen zu SMPng unzufrieden und das führte dann zu DragonflyBSD.

Hat das Einfluss auch FreeBSD_13? oder machen die wieder was ganz Neues?
Nein. FreeBSD 13 hat einen eigenständigen Ansatz. Der ist nicht mal radikal anders als der lock-basierte Ansatz, den man bisher genutzt hat. Man tauscht "nur" in kritischen Pfaden Locks gegen hauptsächlich im Rahmen von Concurrency Kit - http://concurrencykit.org - entwickelte lockfreie Synchronisations- und Ressourcenverwaltungsmechanismen - vor allem Epochs - aus. Teilweise hat man die Gelegenheit genutzt und den jeweiligen Code komplett überarbeitet, beispielsweise hat FreeBSD 13 komplett neuen Routing-Code. Algorithmisch sind Epochs eine Weiterentwicklung des patentverseuchten RCU des Linux-Kernels (https://patents.google.com/patent/US7353346B2/en), man könnte RCU auf Basis von Epochs implementieren.
 

zoidb3rg

Well-Known Member
Oben