Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsAmpere Computing: Zweimal 192 Kerne sind schon zu viel für Linux
Damit Speicher für cpumask dynamisch verwaltet werden kann, brauchts aber überhaupt erstmal einen Patch. Die Funktionalität ist für X86 implementiert, aber nicht für ARM.
Eine solche Änderung Out of Tree zu haben, damit die eigene Hardware läuft wäre ein mittelprächtiger Fuckup.
Wieso ist das ein Fuckup? Das wird doch ständig gemacht, man siehe nur mal im Androidsystem. Da baut sich jeder Hersteller seine eigenen Treiber in den Kernel die out-of-tree sind.
Piktogramm schrieb:
Wer kennt es nicht, Kernelpatches aus Werbegründen einreichen um Artikel auf Phoronix und vielleicht lwn.net zu bekommen
@klausk1978
Und? Rhel macht komisches Zeug Out of Tree und erschwert den Zugang zu ihren Anpassungen nach der IBM Übernahme. Würde ich als Ampere meine Hardware verticken wollen, würde ich meinen Kunden auch kein RedHat mehr ans Bein binden wollen sondern mainline patchen.
Edit: RedHat macht kein komisches Zeug. Es gibt Parameter, die zur Zeit des Übersetzens gesetzt werden können.
Wo genau ist jetzt das Problem? Sie könnten auch einfach selbst einen Kernel kompilieren, bei dem das Limit angehoben ist, der Quellcode ist ja öffentlich. Der Patch ist ja dann nur noch dafür da, dass sie das nicht jedes mal bei jedem Kernel-Update selbst nochmal machen müssen.
Sie haben es sich fast schon selbst beantwortet. Forken und Patchen kann man bis zu einer gewissen Grenze, aber der Sinn von quelloffener Software ist, dass man sich zusammen tut. Die wollen sicher nicht ewig Patchen (Arbeitsaufwand) und die Anwender (Anleitung lesen, Patch bei jedem Release...) auch nicht. Anwender sind allgemein, dankbar, wenn alles Out-Of-The-Box laeuft.
Abgesehen davon ist moeglichst flexible und schlanke Software natuerlich sinnvoll. Interessant waere der Hintergrund, warum das Image allein durch die Unterstuetzung etwas groesser wird. Hat es historische oder direkte technische Gruende?
Ich wollte damit auch zum Ausdruck bringen, dass Nutzer (Rechenzentrumsbetreiber) und Hersteller, die solche Prozessoren verwenden bzw. herstellen, kein Problem damit haben mal fix einen Patch in den Kernel zu spielen. Ampere muss, wenn sie einen anständigen Support wollen die Patches so oder so beim Linuxkernelteam einreichen, oder einen eigenen Maintainer dafür einbringen, wenn sie da regelmäßigen Patchsupport wollen. Ergo ist 99% der Arbeit eh von Ampere zu leisten.
Damit Speicher für cpumask dynamisch verwaltet werden kann, brauchts aber überhaupt erstmal einen Patch. Die Funktionalität ist für X86 implementiert, aber nicht für ARM.
Eine solche Änderung Out of Tree zu haben, damit die eigene Hardware läuft wäre ein mittelprächtiger Fuckup.
Ich glaube der Artikel beschreibt die Funktionalitaet von CPUMASK_OFFSTACK etwas ungluecklich. Das scheint eben dieser dynamische Modus zu sein, nur fuer X86.
PS: Die 4MB sind wahrscheinlich schon auf einem Fitnesstracker entscheidend. Die haben vielleicht vier Kerne, wenn das absoluter High-End von Garmin ist. Wenn das eher ein Embedded-Device von vor zehn Jahr in einer Maschine ist, ist das viel zu viel. Auch wenn jemand bei der Paritionierung auf X86 sparsam war, merkt man die 4MB.
@LorD-AcE
Out of Tree Patches sind bei Betreibern von Rechenzentren unbeliebt. Wenn da die technischen Abteilungen mitreden dürfen, wird sowas gemieden.
Und ich hab mal noch fix die Diskussion auf der Mailingliste gelesen. Zum einen gibt es Parameter, die man auch jetzt bereits zum Zeit des Compilings setzen kann um auf Aarch64 mehr als 256Kerne nutzen zu können. Ampere will sich aber wohl nicht darauf verlassen, dass das typ. Distributionen auch tun und wollte daher ein bisschen was in mainline ändern.
Die Zuständigen Maintainer für Aarch64 (die haben komische Mailadressen mit @arm.com ..) finden das aber gar nicht so toll. cpumask_offstack finden aber wohl Zuspruch. Naja das geht also jetzt erstmal weiter und ich frage mich, wieso ich SCHONWIEDER Kernelmailingliste lese statt BG3 zu spiel.. AHH
Ergänzung ()
flaphoschi schrieb:
Ich glaube der Artikel beschreibt die Funktionalitaet von CPUMASK_OFFSTACK etwas ungluecklich. Das scheint eben dieser dynamische Modus zu sein, nur fuer X86.
Wenn ich es richtig verstehe ist cpumask_offstack bereits plattformunabhänig implementiert.
In dem Verlauf, wird aber auch auf ne ältere Diskussion verwiesen, die zu lesen wäre, wenn man das verstehen will. Ich spiel jetzt aber BG3 mit Patch5!
Na der Code wird größer. Damit braucht man mehr Register und es passt eventuell nicht mehr in den L1. Man muss für Performance kritische Sachen dann eventuell statt nur genau einer Bit-Operation mehrere machen. Ist dann also um Faktoren langsamer.
Gibt da sehr sehr viele mögliche Gründe. Die reinen 4KB werden es eher nicht sein, wobei im Embedded ARM Bereich eventuell auch das weh tut, weil die Systeme wirklich minimal sind. Daher macht man das ja im Allgemeinen zur compilezeit konfigurierbar. Vor paar Jahren hatte ich glaub unter RedHat 7 auch das Problem das die 64 Core Dual Socket AMD Kisten mit SMT nicht liefen. Musste man auch erst den entsprechenden Schalter Umlegen. Das ist also.überhaupt nicht spezielles.
Northstar2710 schrieb:
Wird die Option CPUMASK_OFFSTACK aktiviert, dann können Ressourcen freigegeben werden, statt sie vorzuhalten.
Bis zu 8.192 Kerne werden dann von Linux unterstützt.
Was heißt das jetzt genau?
Ein Kern Limit von 256 , limitiert auch die threads auf 256? Oder ist damit Smt/HT nicht betroffen? So das nur 256kerne limitiert werden aber 512threads laufen können?
Das heißt, dass der Kernel eben nur 256 Cores verwalten kann. Entweder startet das System dann garnicht oder aber du siehst halt im OS nur 256 cores selbst wenn die Hardware 512 cores hat.
Bei großen SMP Systemen hat man da auch unter x86 was drehen müssen.
Man bedenke die alten SGI Kisten mit NUMA Link hatten glaub bis zu 2048 CPUs mit glaub bis zu oder 12 cores jeweils.
Und das lief damals auch schon.
Der Linux Kernel ist da sehr flexibel. Wenn man es nicht braucht wird das Zeug aber auch nicht eingebaut wenn es Performance kosten könnte. Das macht man dann wenn es nötig ist u d daran ist auch überhaupt nichts seltsam oder problematisch.
Weil sie Platz auf dem waver benötigen. Je mehr Platz benötigt wird desto weniger Chips kann man verkaufen und desto höher der Verlust wenn einer auf dem Waver schon kaputt ist.
Deswegen hat sich AMD auch für diese Chiplets entschieden. Das im Prinzip nichts anderes ist als mehrere CPUs und Nothbridge unter einer Kupferplatte.
Ist halt schon ein unterschied ob von 500 stück einer defekt ist oder von 50 stück einer defekt ist.
Ich beschäftige mich beruflich mit IT-Infrastruktur-Automatisierung im Government/Banking-Bereich. Dort gibt es zu fast zu 100% IBM, RedHat (oder Oracle, wenn es sich um Datenbank-Cluster handelt). So Bastlerdinge wie Debian etc.. zu deployen, kannst im Enterprise-Bereich vergessen. So etwas ist, wenn man zB ein Webhoster ist, wo die Requirements ziemlich trivial sind, eh ganz 'nett'. Von so Hobby-Projekten wie Arch rede ich erst gar nicht, das ist eher die Bastler-Schiene.
Die Adverben "schon" und "bereits" sind fehl am Platze, wenn man sich die Historie anschaut: Kernel 2.0 von 1996 hatte erstmals Unterstützung für symmetrisches Multiprocessing eingebaut.
Nichts für ungut, aber wo außerhalb von ein paar Lösungen wie TrueNAS oder pfSense und vielleicht irgendwelchen Universitäten wird denn FreeBSD eingesetzt? 🤡
So viele Enterprise-Umgebungen sind mir in 20 Jahren Consulting damit noch nicht untergekommen.
