Linux Kernel nach Maß bauen

[9Strike]

Also eigentlich solltest du gcc8 einfach mit

apt install gcc8

installieren können. Wenn du über das Repo an gcc9 kommst kannst du auch gleich gcc9 nehmen. Ist aber glaub noch nicht offiziell draußen. Der Vega Support in gcc9 bezieht sich nur auf Support für OpenMP, als nicht relevant wenn du deinen Kernel compilen willst.

Kannst auch erstmal gcc7 nehmen und gucken obs klappt, weiß aber nicht ob da schon die Ryzen Optimierungen drin sind.

Den Patch installierst du btw mit

patch -p1 < enable_additional_cpu_optimizations_for_gcc_v8.1+_kernel_v4.13+.patch

(da brauchste gcc 8.1 für, ansonsten halt entsprechend die anderen Dateien aus dem Patch probieren)

 

[root@linux]

apt search gcc 8

apt install gcc 8.2

E: Unable to correct problems, you have held broken packages.

Den Patch habe ich schon installiert. In dem Patch ist aber keine Vega-GPU dabei. Im GCC 7.4 wurden AMD und Vega hinzugefügt.

Quelle: GCC
AMD GCN support [2019-01-17]
GCC support for AMD GCN Fiji and Vega GPUs has been added. This back end was contributed by Mentor Graphics.
GCC 7.4 released [2018-12-06]

Ergänzung (2. Februar 2019)

Mal ne andere Frage.
lspci -v zeigt mir die Ethernet/Netzwerk-Karte als RTL8111 an, installiert aber den R8169 Treiber, einen RTL8111 Treiber gibt es nicht, dafür aber einen AMD8111 Treiber.
Ich habe in der make menuconfig den AMD8111 zum installieren markiert (*) und den RTL8169 als Module (M) markiert, in der Hoffnung das der AMD8111 bevorzugt wird und benutzt, macht er aber nicht.
Welcher Treiber ist jetzt der richtige?

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)
Subsystem: Acer Incorporated [ALI] RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
Flags: bus master, fast devsel, latency 0, IRQ 35
I/O ports at 2000 [size = 256]
Memory at e0904000 (64-bit, non-prefetchable) [size=4K]
Memory at e0900000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Capabilities: [178] L1 PM Substates
Kernel driver in use: r8169
Kernel modules: r8169

 

[Piktogramm]

Frag halt $Suchmaschine was AMD8111 für ein Gerät ist und dann noch mal "linux driver rtl8111" damit lässt sich die Frage doch recht gut beantworten.

 

[root@linux]

cd /usr/src/linux-4.20.5

patch -p1 < /root/Desktop/kernel_gcc_patch-master/enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v4.13+.patch

Richtig so?

Ergänzung (2. Februar 2019)

root@linux:/usr/src/linux-4.20.5# patch -p1 < /root/Desktop/kernel_gcc_patch-master/enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v4.13+.patch
patching file arch/x86/include/asm/module.h
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file arch/x86/include/asm/module.h.rej
patching file arch/x86/Kconfig.cpu
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
11 out of 11 hunks ignored -- saving rejects to file arch/x86/Kconfig.cpu.rej
patching file arch/x86/Makefile
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/x86/Makefile.rej
patching file arch/x86/Makefile_32.cpu
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file arch/x86/Makefile_32.cpu.rej

Ergänzung (2. Februar 2019)

Habe eine tinyconfig gemacht und jetzt ist nichts angekreuzt.
Ich brauch nur das Internet, das TCP/IP V.4 Protokoll und sonst nichts.
Geht das?
Was muss ich hier alles ankreuzen?

 

[andy_m4]

Ich wusste gar nicht, dass heutzutage noch jemand den GCC verwendet, wo es doch clang/LLVM gibt. :-)

 

[9Strike]

Ich wusste gar nicht, dass heutzutage noch jemand den GCC verwendet, wo es doch clang/LLVM gibt. :-)

Du kannst Linux im Moment (noch) nicht mit clang compilen.

 

[root@linux]

An diese stalle bin ich etwas ratlos.
Welche Werte soll ich bei:
MTRR cleanup enable value
und
MTRR cleanup spare reg num
eingeben?

MTRR (Memory Type Range Register) support

Wie zu sehen, der Ryzen unterstützt MTRR und PAT

nano /proc/cpuinfo

Habe diese Seite: community.amd.com gefunden, aber ich blicke da nicht durch.

Ergänzung (2. Februar 2019)

Ach ja, der Patch hat gefunzt
DANKE !!!

Ergänzung (2. Februar 2019)

.
Laut AMD hat die Ryzen 5 2500U Vega APU, 4-CPU und 8-GPU Kerne = 12
Soll ich die Maximum number of CPUs auf 12 oder 16 reduzieren?

AMD Ryzen 5 2500U​

 

[andy_m4]

Du kannst Linux im Moment (noch) nicht mit clang compilen.

Sprich: der Linux-Kernel hält sich an keine Standards und benutzt GCC-spezifisches Zeug.
Wurde das mit dem nicht an Standards halten nicht immer Microsoft vorgeworfen? ;-)

 

[Piktogramm]

@root@linux
Es interessiert nur die Anzahl an CPU Kernen bzw. CPU-Threads. Die GPU zählt in diesem Kontext nichts. Die Anzahl der CPU Cores künstlich zu limitieren ist ansonsten schlicht unnötig.

Bei den restlichen Fragen müsste ich soviel Arbeit investieren wie du.

 

[K7Fan]

An diese stalle bin ich etwas ratlos.
Welche Werte soll ich bei:
MTRR cleanup enable value
und
MTRR cleanup spare reg num
eingeben?

1 und 8 minus der Anzahl an benötigten MTRR.
Einfach mal mit 4 spare regs testen, die Anzahl kann jeder Zeit über den Bootparameter mtrr_spare_reg_nr geändert werden.

Sind MTRR nicht dank PAT inzwischen weitgehend obsolet?

Soll ich die Maximum number of CPUs auf 12 oder 16 reduzieren?

Wenn überhaupt dann IMHO 8.

 

[9Strike]

Sprich: der Linux-Kernel hält sich an keine Standards und benutzt GCC-spezifisches Zeug.
Wurde das mit dem nicht an Standards halten nicht immer Microsoft vorgeworfen? ;-)

Das siehst du zu einfach. Es ist technisch schon möglich, Linux mit clang zu compilen, das haben auch schon Leute gemacht. Tatsächlich verwendet der Kernel in manchen Stellen Arrays mit variabler Länge, die einer Erweiterung von C durch gcc für den Linux Kernel darstellen, allerdings sind diese durchaus dokumentiert. Afaik ist das Ziel, diese Arrays jedoch komplett zu ersetzen, so dass ein compilen mit clang problemlos geht.
Du darfst nicht vergessen, dass bei vielen Anwendungen Stabilität vor Performance steht, und gcc ist im Gegensatz zu clang jahrelang der Standard-Compiler für den Kernel geworden.

 

[aki]

Gib mal dmesg ein und suche relativ weit oben nach sowas ähnlichem:

[    0.001187] MTRR variable ranges enabled:
[    0.001188]   0 base 000000000000 mask 3FFC00000000 write-back
[    0.001189]   1 base 000400000000 mask 3FFFC0000000 write-back
[    0.001189]   2 base 0000BF000000 mask 3FFFFF000000 uncachable
[    0.001190]   3 base 0000C0000000 mask 3FFFC0000000 uncachable
[    0.001190]   4 disabled
[    0.001190]   5 disabled
[    0.001190]   6 disabled
[    0.001191]   7 disabled
[    0.001191]   8 disabled
[    0.001191]   9 disabled

Die Anzahl an "disabled" müsste deine spare reg num sein. In diesem Fall wären die beiden Werte also 1 und 6

 

[root@linux]

Gib mal dmesg ein

Damit kann ich was anfangen. Danke!

Diese Fehler sind aus der SUSE-config, die ich ein wenig modifiziert habe.

Fehler 1

[ 0.577858] ACPI BIOS Error (bug): Failure creating [\_SB.PCI0.LPC0.EC0._Q46], AE_ALREADY_EXISTS (20181003/dswload2-316)
[ 0.577870] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20181003/psobject-221)
[ 0.577874] ACPI Error: Skip parsing opcode Method (20181003/psloop-543)
[ 0.577882] ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.GPP2.BCM5], AE_NOT_FOUND (20181003/dswload2-160)
[ 0.577888] ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20181003/psobject-221)
[ 0.577892] ACPI Error: Ignore error and continue table load (20181003/psobject-604)
[ 0.577895] ACPI Error: Skip parsing opcode Scope (20181003/psloop-543)

Fehler 2

[ 0.134463] [Firmware Bug]: AMD-Vi: IOAPIC[4] not in IVRS table
[ 0.134467] [Firmware Bug]: AMD-Vi: IOAPIC[5] not in IVRS table
[ 0.134469] [Firmware Bug]: AMD-Vi: No southbridge IOAPIC found
[ 0.134470] AMD-Vi: Disabling interrupt remapping

Fehler 3

[ 10.105450] AMD-Vi: Unable to write to IOMMU perf counter.

Hat wohl was mit PCI zutun. Kann mir jemand bei diesen Einstellungen helfen?

------------------------------------

Das ist ne neue config (Kernel: 4.20.5-A315-41-R001) die ich mache, auf Basis von

make tinyconfig

, also von null.

 

[K7Fan]

Die Anzahl an "disabled" müsste deine spare reg num sein. In diesem Fall wären die beiden Werte also 1 und 6

Zum Zeitpunkt etwas vor 0,00119 stimmt das, die Situation danach kann und sollte dem zwar entsprechen, muss aber nicht.

cat /proc/mtrr sollte den aktuellen Zustand zeigen.

Fehler 2

Boote mal mit amd_iommu_dump=1 und poste was dmesg | grep "AMD-vi" sagt.

 

[andy_m4]

Tatsächlich verwendet der Kernel in manchen Stellen Arrays mit variabler Länge, die einer Erweiterung von C durch gcc für den Linux Kernel darstellen, allerdings sind diese durchaus dokumentiert.

Sag ich ja: Man nutzt GCC-Eigenheiten.

Du darfst nicht vergessen, dass bei vielen Anwendungen Stabilität vor Performance steht, und gcc ist im Gegensatz zu clang jahrelang der Standard-Compiler für den Kernel geworden.

Hätte sich Linux von Anfang an an Standards gehalten, gäbe es das Problem gar nicht.

 

[aki]

Ok, dann eine Mischung aus dmesg und cat /proc/mtrr Ansonsten weiß man nicht, wie viele Register überhaupt verfügbar sind.

 

[9Strike]

Sag ich ja: Man nutzt GCC-Eigenheiten.

Was heißt schon Eigenheiten. Wenn du das so betrachtest ist C++ auch nur C mit ein paar "Eigenheiten".
Niemand hat behauptet, dass der Linux Kernel im strikten C99 Stil geschrieben ist.
Sobald etwas dokumentiert ist, kannst du es als Standard ansehen.

Hätte sich Linux von Anfang an an Standards gehalten, gäbe es das Problem gar nicht.

Quatsch, ein Compiler ist hochkomplex, es ist gar kein Problem Linux so zu compilen wie der Code es sagt (vorrausgesetzt du implementierst die Arrays in den Compiler, sollte aber nicht allzu schwer sein).

Das Problem ist, den Code effizienter zu machen als ein blindes Übersetzen und trotzdem keine Fehler einzubauen. Afaik hat das compilen von Linux schon so manche Fehler in gcc und auch in clang aufgedeckt.
Es ist kein Zufall, dass manche compiler schnelleren Code generieren können, was damit verbunden ist, dass sich keiner strikt an die Standards hält, sondern versucht den Code effizient umzusetzen. gcc kann auf -03 ganze Teile von Code weglassen, wenn diese nie ausgeführt werden können, Funktionen, Variablen oder Abfragen durch Ersetzen der Aufrufe quasi verschwinden lassen und noch so einiges mehr. Das ist vom Code nicht vorgesehen, aber am Ende gibt es dir Performance-Schübe.
Wenn die Arrays damals eine gute Lösung für den Kernel waren, kannst du es den Entwicklern kaum vorwerfen, diese verwendet zu haben. Wie gesagt, es ist nicht so als wären die nicht dokumentiert gewesen. clang hatte Gründe diese nicht zu implementieren, es war auch nicht das Ziel von clang den Kernel compilen zu können. clang kann dafür andere Sachen, die gcc nicht kann. Ist das jetzt die Schuld von clang?

 

[andy_m4]

Wenn du das so betrachtest ist C++ auch nur C mit ein paar "Eigenheiten".

Schlechtes Beispiel. C++ ist eine vollkommen eigene Sprache. C ist nicht mal ne echte Untermenge von C++.

Niemand hat behauptet, dass der Linux Kernel im strikten C99 Stil geschrieben ist.
Sobald etwas dokumentiert ist, kannst du es als Standard ansehen.

So ein Quatsch. Standards ist das, wo sich alle dran halten. Wo man sich drauf geeinigt hat oder wie auch immer.
Ein standardkonformer Quelltext muss sich also von jedem standardkonformen Compiler übersetzen lassen. Alles andere hat nix mit Standard zu tun.

Wenn die Arrays damals eine gute Lösung für den Kernel waren, kannst du es den Entwicklern kaum vorwerfen, diese verwendet zu haben.

Na was heißt Vorwurf. Kann man machen. Kann sogar Sinn machen oder von mir aus auch gar nicht anders lösbar sein, aber ist dann halt nicht mehr standardkonform.
Ob die Not übergroß war, wage ich aber zu bezweifeln. Wie Du schon sagtest. gcc war eben lange Zeit im Linux-Umfeld gesetzt. Da musste man sich keinen Kopp drum machen. Da hat man sich gesagt "Nehmen wir ne saubere Lösung oder eine Pragmatische. Und bei sowas behält in der Regel bei Linux die Pragmatische die Oberhand".

Ist ja auch alles kein Problem. Das können die Linux-Leute halten wie sie wollen. Ist ja ihr Projekt.
Nur wenn man es schon anspricht, soll man auch offen und ehrlich dazu stehen und versuchen es zu relativieren.

 

[9Strike]

Historisch war C++ tatsächlich nur eine Erweiterung von C (Entstehung 1979), die erst 1998 richtig standartisiert wurde (siehe Wikipedia).

Btw ich hab gerade geguckt Linux ist in GNU C geschrieben, das ist durchaus ein richtiger Standard. Wichtiger Grund für GNU C ist die Möglichkeit inline Assembler zu benutzen.

Ich sag ja auch nicht, dass ich es gut finde, dass man Linux nicht "einfach so" mit clang compilen kann. Das es nicht so trivial geht heißt aber nicht, dass das zwingend schlecht ist.
clang kann dafür Sachen, die gcc nicht kann. Beide compiler haben ihren Zweck, aber der von clang ist es im Moment eben noch nicht den Kernel zu compilen.

Und ganz abgesehen davon ist clang im Schnitt jetzt auch nicht so viel besser, es gibt Bereiche in denen mal der eine und mal der andere besser ist.

 

[root@linux]

Versuche gcc 8.2 zu installieren, geht aber nicht.

apt install gcc-8
Reading package lists... Done
Building dependency tree
Reading state information... Done
gcc-8 is already the newest version (8.2.0-1ubuntu2~18.04)

make -v
GNU Make 4.1

gcc -v
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)

Was soll ich jetzt machen

Ergänzung (3. Februar 2019)

Ich brauche unbedingt gcc mit Vega und zen

Ergänzung (3. Februar 2019)

Meine Vermutung ist, dass die Ryzen APU als 8-Core CPU erkannt wird, weil sie 4-CPU-Kerne und 4-doppel-GPU-Kerne hat. Die Doppelkerne werden nur als Einzelkerne erkannt und somit ergibt sich die magische Zahl 8.

Mein Hoffnung ist, das die APU mit dem neuen cgg richtig erkannt wird.

AMD GCN support [2019-01-17]
GCC support for AMD GCN Fiji and Vega GPUs has been added. This back end was contributed by Mentor Graphics.

Btw hier das mit den optimierten compile Optionen: https://github.com/graysky2/kernel_gcc_patch

Dieser Patch ist ein Fake. Es werden nur Namen in das Auswahlmenü hinzugefügt, im System ändert sich nichts.

Ergänzung (3. Februar 2019)

Wenn ihr euch fragt, wie ich das mache, dass hinter der Kernel Version 4.20.5-SUSE oder AMD steht.
Hier die Lösung