Halbwissendisclaimer!
Von dem was ich aus dem Überfliegen der cpumask.h und cpumask.c aus dem Kernelrepo mitbekomme und mir zusammenreime.
SaschaHa schrieb:
Könnt ihr da mal nachhaken und erklären, was es damit genau auf sich hat? Wieso wächst das Image mit steigender Kernanzahl?
Der Bootloader liest das Kernelimage vom Festspeicher und schreibt dieses in den Ram um dann an den Kernel zu übergeben. Damit der Kernel gleich von Anfang an die CPU Kerne gescheit verwalten kann, ist der Speicherbereich für die cpumask direkt von Anfang an initialisiert, weil es schlicht und ergreifend ein Teil dessen ist, was als Kernelimage in den Ram geschrieben wurde.
Imho nicht sonderlich elegant, aber ein typischer Tausch zwischen Speicherplatz und Laufzeit beim Initialisieren von Hardware (hier halt CPU-Kernen)
/Halbwissendisclaimer
TriceO schrieb:
Ich bin da zugegebenermaßen unterbelichtet, aber wieso muss der Kernel überhaupt so klein wie möglich gehalten werden?
128 Kerne * 8KB = 1MB, 512 Kerne * 8 = 4MB
Wieso sind 2023 die Megabytes so kostbar?
Verstehe ja, dass man überhaupt entsprechende Systeme zum Testen benötigt, aber das 8KB-Hindernis lässt mich verwundert zurück.
Linux wird in kleinen Systemen eingesetzt. Yoctolinux zum Beispielt ziehlt auf Images ab, die mit 8MB Arbeitsspeicher laufen können und unkomprimierten Kernelimages von ab 1,5MB ohne all zu sehr Funktionseinschränkungen zu unterliegen. Yocoto mag ein extemeres Beispiel sein, aber Kernelimages die ohne Not ~4MB größer sind als nötig ist für einige Projekte bereits problematisch.
Und ohne die Kernelmaintainer nehmen generell ungern Patches an für nicht existente Hardware. Klar, manchmal wirkt das komisch, weil absehbar ist, dass in wenigen Jahren ein Stand erreicht sein wird, aber die Regeln wann/was aufgenommen wird sollen auch nicht zu kompliziert sein. Die Regel an sich ist ja sinnvoll, damit man Patchspam zu Vaporware ablehnen kann.
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.
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.
