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
Der "Fehler" bzw die Verantwortung dafür, daß Linux bis heute dieses Limit für ARM 64 Bit hat liegt (IMHO) aber bei Ampere. Die wussten doch schon länger das Linux, das Haupt Betriebssystem für ARM Server, dieses Limit hat, und ihre CPU (wenn mehr als eine davon im System) damit Probleme haben wird. Sie hätten eben während oder besser schon vor der Design Phase Patches entwickeln und einreichen können, dann wären sie jetzt bereits in Linux eingepflegt. Sich da auf andere verlassen ist eben risikoreich.
@eastcoast_pete
Das harte Limit liegt bei >8.000 CPUs derzeit. Was Ampere ändern wollte ist schlicht die Standardconfig vom Kernel. Die liegt derzeit bei 256Kernen. Die wussten das auch schon eher, die Diskussionen haben Geschichte
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.. [...]
Kommt immer drauf an wo man sich umtreibt. Banken die auf Cobol und IBM Mainframes rumhängen und dazu ein 1a Papertrail für die Verantwortung haben wollen sind da sehr konservativ. Wenn man seine CPUs an größere Hoster, BigTech wie Meta, Google verkaufen will, kommt man in Bereiche, wo RedHat schlicht zu teuer wird, dafür aber KnowHow da ist, das HostOS selber zu pflegen.
Ob die Vorteile eines Kernels auf einem Dualsockel gegenüber einem Kernel pro Sockel so groß sind?
HPCs bestehen ja aus tausenden von Prozessoren, da läuft auch nicht nur ein einziger Kernel.
Aber kommt wohl drauf an was man damit macht. Kann schon sein das man lieber einen Kernel mit 2TB Arbeitsspeicher will als 2 mit 1TB.
Ich hätte Stein und Bein geschworen dass das Limit unter x86 bei 1024 CPUs liegt. Allerdings basiert das auf einer Erinnerung an die erste SMP-Unterstützung aus Kernel 1.2. Asynchrone Scheduler, NUMA usw. war da noch in weiter Ferne.
Der ARM-Kernel muss sehr vielseitig einsetzbar sein. ARM-Architekturen findet man vorallem im kleinen, energiesparenden Bereich bisher. Da geht die Optimierung immer Richtung Minimierung der Ressourcen. Ich denke auch, dass die 8KB pro Kern nicht alles sind, was an Overhead dazu kommt wenn man mehr Kerne unterstützt. Das Päkchen schleppt halt dann auch ein 1 oder 2 Kern ARM-System mit sich mit, obwohl es vollkommen sinnlos da ist.
Dass ARM mit so hohen Kernzahlen gebaut wird, ist ja eh erst ein relativ neues Phänomen und ob diese Entwicklung überhaupt Früchte trägt im Sinne von Marktanteilen sei mal dahin gestellt.
Die totgesagte x86-Technik wurde von AMD auch ins 64Bit Zeitalter geführt und mit den Epics hat AMD gezeigt, dass man auf der Technik mit modernen Kernen auch problemlos in Richtung 3 stellig gehen kann.
Mit neuen, schlankeren Kernen wahrscheinlich in ein paar Jahren 4 stellig.
Ist halt die Frage wie ARM hier mithalten will. Es ist ja nicht die überlegene Technik alleine, die einen Markterfolg bringt, sondern in erster Linie, was wirklich gekauft wird. Und da ist die Durchdringung der Technologie im Markt das eigentlich entscheidende. Das hat Intel bereits mit dem Itanium-Fail schmerzhaft erleben dürfen.
Und mal abgesehen davon muss man auch noch sagen:
Die haben seit einem halben Jahr die Technik am Markt und kommen JETZT mit einem Linux-Patch daher?
Warum das nicht während den Jahren Entwicklungszeit davor schon? Muss denen doch klar gewesen sein, dass man hier frühzeitig anklopfen muss, wenn man an einem Produkt arbeitet und Softwareunterstützung will...
Aus meiner Sicht, ohne wirkliche Ahnung von der Materie, einfach mieses Managment der Entwicklung und Vermarktung. Jetzt merken die "Oh, der einzige Einsatzzweck unserer CPU wäre auf Servern, die meist unter Linux laufen und genau das unterstützt aktuell unsere CPUs nicht. Sapperalot..."
ARM-CPUs zu entwickeln ist jetzt keine große Kunst. Die Firma dahinter lebt immerhin von der Entwicklung und den Bauplänen. Firmen die darauf basierend CPUs entwickeln müssen ja für einen großen Teil nur copy&paste machen. Deshalb kann auch eine nahezu unbekannte Firma quasi aus dem Ärmel plötzlich so ein Kern-Monster hervorzaubern.
Um diese Firmen ists meist auch nicht schade. wenn die eingehen, dann kommt halt der nächste, der die Nische übernimmt. Knowhow geht da nicht groß verloren.
Ergänzung ()
Locutus2002 schrieb:
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.
Sowas wird aber NIEMAND einsetzen, der professionell damit arbeitet und solche Systeme einsetzt.
Und genau das ist aber die Zielgruppe solcher CPUs. Nicht die Frickelgemeinschaft die sowas als hobby macht
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
Wie kommst du bitte zu der These? Also wie viel Erfahrung hast du bitte im Bereich Hardwarehersteller und Rechenzenteumsbetreiber?
Also als jemand der für zwei Hardwarehersteller gearbeitet hat und auch mit dem Kernel bze Compiler Support mehr oder weniger zu tun hatte kann ich dir sagen, dass das keiner auf die leichte Schulter nimmt sondern sehr sehr viel Bestreben daran liegt in den Mainlain Kernel aufgenommen zu werden.
Und als jemand der mit vielen Rechenzentren zu tun hatte kann ich dir auch ganz klar sagen das ein fehlender Support in den Standarddistris nen riesen Minuspunkt ist.
LorD-AcE schrieb:
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.
Ne müssen Sie nicht. Also klar wenn Sie gewisse Features mit rein haben wollen müssen Sie mitarbeiten, aber wenn Sie grundsätzlich drin sind mit ihren Änderungswünschen, dann ist das ne ganz andere Hausnummer an Aufwand zu schauen dass das Zeug auch weiterhin funktioniert und nicht kaputt geht. Danach schauen dann nämlich auch Dutzende oder hunderte andere und berücksichtigen das auch und wenn es übersehen wird und was kaputt geht hat man ein ganz anderes Vetorecht als wenn der eigene Code nicht im Kernel drin ist. Man lädt da also unglaublich viel Integrationsaufwand an andere ab.
Sorry, aber wenn ich so was lese dann habe ich ernste Zweifel das da jemand tatsächlich Erfahrung aus erster oder immerhin zweiter Hand hat.
Siehe z.B. das riesen Problem von Openwrt an. Dort wurde auch auf biegen und brechen der Kernel so klein wie möglich gehalten und seit Anfang des Jahres sind die ganzen 4/32er Geräte rausgeflogen. Was doch enorm viele Geräte betrifft. Und wenn man Abhänigkeiten von Openwrt wie z.B. Freifunk mit Gluon betrachtet betrifft es enorm viele Communitys etc. und um von embedded Systemen garincht zu reden.
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.
Welche ungewollten Nebenwirkungen holt man sich mit der Option CPUMASK_OFFSTACK ins Haus?
Man kann mehr Kerne betreiben, aber zu welchem Preis gegenüber einer "offiziellen" Unterstützung von mehr Kernen?
Ob die Vorteile eines Kernels auf einem Dualsockel gegenüber einem Kernel pro Sockel so groß sind?
HPCs bestehen ja aus tausenden von Prozessoren, da läuft auch nicht nur ein einziger Kernel.
Aber kommt wohl drauf an was man damit macht. Kann schon sein das man lieber einen Kernel mit 2TB Arbeitsspeicher will als 2 mit 1TB.
Eben. Wenn die das als shared-memory system bauen (was ein betraechtlicher Aufwand ist), und die Kunden das als shared-memory-system kaufen, dann wollen sie das sicher nicht als zwei Computer mit jeweils der Haelfte an RAM betreiben (ganz abgesehen davon, ob das bei diesen Systemen auch so leicht moeglich ist), zumindest nicht auf der obersten Ebene. Dass dann in vielen Faellen da drinnen viele virtuelle Maschinen arbeiten, jede mit weniger als 256 Prozessoren, mag schon sein.
Virtuelle Maschinen sind uebrigens ein Grund, warum man den Kernel nicht unnoetig gross konfiguriert bzw. dynamisch konfigurierbar macht. Wenn man x davon hat, kostet die grosse Konfiguration gleich x mal soviel Speicher wie beim Kernel, der direkt auf der Hardware sitzt.
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.
Kannst du da mal genauer werden, was du genau meinst? Also warum eignet sich RedHat besser als Debian? Ist eine ernst gemeinte Frage, da ich auch eher aus dem Webserver Bereich komme und mit Ubuntu gut fahre. Ich weiß das RedHat bei Business beliebt ist, aber frage mich eben immer, was da wirklich die Unterschiede sind. =) Vielleicht kannst du/jemand mich erleuchten.
Damit der Kernel schneller geladen werden kann.
Sonst könnte man ja auch gleich direkt alle existierenden Kernel Module mit laden, die man irgendwann einmal benötigen könnte.
Wie kommst du auf 8kb/Kern?
Ich konnte in dem ganzen Artikel nichst darüber lesen!
1. Support und Service: IBM und Red Hat bieten umfassenden professionellen Support für ihre Produkte an. Große Unternehmen, insbesondere in Branchen wie Rechenzentren, Regierungen und Banken, benötigen oft einen hohen Grad an Unterstützung, Schulung und Wartung. Diese Unternehmen sind bereit, für den Support zu zahlen, den IBM und Red Hat bieten können.
2. Stabilität und Zuverlässigkeit: IBM und Red Hat stehen für Stabilität und Zuverlässigkeit in der Software. Ihre Produkte werden oft als konservativ angesehen, was für Branchen, die strenge Sicherheits- und Stabilitätsanforderungen haben, attraktiv ist. Debian, während es eine solide Linux-Distribution ist, wird manchmal als weniger konservativ angesehen und hat möglicherweise nicht den gleichen Grad an Garantien und Unterstützung wie die Produkte von IBM und Red Hat.
3. Zertifizierungen und Compliance: In Bereichen wie Banken und Regierungen sind spezifische Zertifizierungen und die Einhaltung von Vorschriften von größter Bedeutung. IBM und Red Hat investieren oft erheblich in die Zertifizierung ihrer Produkte, um sicherzustellen, dass sie den branchenspezifischen Standards und Vorschriften entsprechen.
4. Integration und Ökosystem: IBM und Red Hat bieten oft ein umfassendes Ökosystem von Softwareprodukten und Dienstleistungen an, die nahtlos integriert werden können. Dies ist für große Unternehmen von Vorteil, da sie möglicherweise eine breite Palette von Anwendungen und Diensten benötigen, die gut miteinander funktionieren.
5. Marktposition und Reputation: Die lange Geschichte, der Ruf und die Marktposition von Unternehmen wie IBM und Red Hat sind für viele Unternehmen attraktiv. Die Stabilität und der Erfolg dieser Unternehmen können das Vertrauen in ihre Produkte stärken.
IBM hat RedHat gekauft, das ist der gleiche Laden. Und nicht vergessen, dass auch viel Software in deren Distributionen von den "Bastlern" kommt. Aber der ganze Zertifizierungszirkus ist in meinen Augen hauptsächlich soetwas wie moderner Ablasshandel, so dass man im Katastrophenfall nicht selbst im Kreuzfeuer steht. Schließlich hat man ja zertifizierten kram eingekauft.
Relativ in der Mitte des Artikels, mit der Überschrift "Patch soll das CPU-Limit anheben":
Dass überhaupt solch niedrige Limits wie bisher bestehen, liegt daran, dass mit jedem unterstützten Kern das Kernel Image um rund 8 KB anwächst. Wird die Option CPUMASK_OFFSTACK aktiviert, dann können Ressourcen freigegeben werden, statt sie vorzuhalten, und so sind noch deutlich mehr Kerne nutzbar: Bis zu 8.192 Kerne werden dann von Linux unterstützt.
IBM hat RedHat gekauft, das ist der gleiche Laden. Und nicht vergessen, dass auch viel Software in deren Distributionen von den "Bastlern" kommt. Aber der ganze Zertifizierungszirkus ist in meinen Augen hauptsächlich soetwas wie moderner Ablasshandel, so dass man im Katastrophenfall nicht selbst im Kreuzfeuer steht. Schließlich hat man ja zertifizierten kram eingekauft.
Meine 2 ct:
In einem Multithreading System mußt du die mindestens alle Register der CPUs (inkl. SIMD Register, je virtuellem Kern nicht nur je physischem Prozessorkern) in den Speicher auslagern können. Damit die gerade inaktiven Threads später fortgesetzt werden können. Nur die Daten des gerade aktiven Threads stehen in den pyhsischen Registern.
Hängt jetzt sehr von CPU Variante und Architektur ab deswegen kann ich's nur am Beispiel rechnen: ein typischer CPU Registersatz könnte in der Größenordnung 32 Register a 64 Bit liegen, ein typ. SIMD Registersatz bei z.B. doppelter 32 Register a 256 Bit Block. Macht 2304 Byte. Bei 2fach Hypherthreading dann eben das Doppelte je physischem Core. Das Ganze muß man dann natürlich noch mit der Zahl der gerade aktiven Threads die der Linux Kernel selbst nutzt, der Speicherbedarf für die Anwenderthreads gehen ja nicht auf das Konto des OS, multiplizieren. Waren das nicht auch 2 ?
Es ist tatsächlich einfach eine build-Konstante, die frei bis 4096 gesetzt werden kann.
Ist trotzdem ärgerlich, wenn man die neue Hardware hat, die eigene Distro den default-Wert lässt und man dshalb den Kernel neu compilieren müsste...
