Linux Kernel GCC flags

[Ronnie N]

Hallo allen!

Sinds kort compileer ik m'n eigen kernel. De prestatie verschillen zullen miniem zijn, maar het is leuk om te doen en leerzaam.

Op dit moment gebruik ik de volgende "flags":

code:

CFLAGS="-march=native -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
LTOFLAGS="-flto=auto"

Nu ben ik me druk aan het inlezen over wat de verschillende opties precies doen, maar waar ik vooral geinteresseerd in ben, zijn er mensen hier die een kernel draaien gecompileerd met -O3?.

Ik lees er verschillende dingen over, en benchmarks zijn lastig te vinden.

Side-note: Het compileren van m'n eigen Proton voor Steam games geeft wel degelijk prestatie verbeteringen, vooral in de minima.

[Mijzelf]

Het lijkt me dat je -fexceptions zonder meer kan weglaten. Daarmee zorg je dat de stack op zo'n manier wordt opgebouwd dat bij excepties de stack netjes kan worden afgebroken. Dat levert meer code (die wordt uitgevoerd) en gebruikt meer stackruimte. Maar de kernel is geschreven in C, en gebruikt helemaal geen excepties.
Ik heb mijn twijfels over -fstack-clash-protection en -fcf-protection. De eerste zorgt dat je niet over de stack guard page heen kunt springen (ten koste van extra code). Eigenlijk geen idee of de kernel uberhaubt guardpages gebruikt, maar als je die protectie nodig hebt heb je òf een bug, òf malware in je proces. De tweede is een malware protectie, die tegen bepaalde soorten malware injectie beschermt (ten koste van extra code). Volgens Wikipedia gebruikt de W10 kernel cf protectie, maar ik vraag me af hoe die malware wordt geacht in de kernel te komen, en wat je reactie zou moeten zijn. Blue screen, neem ik aan. Nou heeft Windows natuurlijk wel meer kans op vage code in de kernel (3th party device drivers) dan Linux, waar alle device drivers bij de kernel source horen.

[danslo]

offtopic:
Ik draai geen eigen kernel, maar verreweg de grootste performance boost kreeg ik door mitigations=off te gebruiken - de performance<>security afweging moet je zelf maken.

[GarBaGe]

Ik heb jarenlang Gentoo gedraaid (alles uit source compileren) en gespeeld met allerlei soorten vlaggen.
Je vraag over "-O3" is heel moeilijk te beantwoorden.
De uitwerking van veel compiler flags zijn erg hardware / processor specifiek.
Sommige vlaggen werken op een processor positief, maar op een andere negatief.
En dan is er ook nog een afhankelijkheid van de code die je compileert.
De ene vlag kan 1 applicatie sneller maken, maar een andere weer langzamer.

Wil je het maximale van het maximale, moet je eigenlijk per applicatie een andere set vlaggen gaan bijhouden

Edit: op de lange termijn vond ik de side-effects van alles zelf compileren niet fijn meer en ben ik terug overgestapt naar meer mainline distros

[ Voor 11% gewijzigd door GarBaGe op 19-04-2022 13:15 ]

[Ronnie N]

Mijzelf schreef op dinsdag 19 april 2022 @ 12:21:
Het lijkt me dat je -fexceptions zonder meer kan weglaten. Daarmee zorg je dat de stack op zo'n manier wordt opgebouwd dat bij excepties de stack netjes kan worden afgebroken. Dat levert meer code (die wordt uitgevoerd) en gebruikt meer stackruimte. Maar de kernel is geschreven in C, en gebruikt helemaal geen excepties.
Ik heb mijn twijfels over -fstack-clash-protection en -fcf-protection. De eerste zorgt dat je niet over de stack guard page heen kunt springen (ten koste van extra code). Eigenlijk geen idee of de kernel uberhaubt guardpages gebruikt, maar als je die protectie nodig hebt heb je òf een bug, òf malware in je proces. De tweede is een malware protectie, die tegen bepaalde soorten malware injectie beschermt (ten koste van extra code).

Dank voor je uitgebreide reactie, ik heb een beetje rond gelezen, en ik denk dat je gelijk hebt. Ik bouw de kernel met custom Xanmod patches, die ik wel even door heb genomen natuurlijk .

GarBaGe schreef op dinsdag 19 april 2022 @ 13:13:
Op de lange termijn vond ik de side-effects van alles zelf compileren niet fijn meer en ben ik terug overgestapt naar meer mainline distros

Ja, ik ben ook zeker niet van plan om alles zelf te compileren, maar ik merk bij bepaalde programma's wel degelijk prestatie winst (na benchmarken), zoals bij Wine/Proton.

Het schijnt dat het zelf compileren van Mesa ook prestatie verbetering met zich mee kan brengen, maar omdat ik dan ook de hele LLVM stack moet meenemen begin ik er maar niet aan. Het moet ook niet te moeilijk worden voor iemand die alleen in R en Python script .

[KillerZero86]

Je moet trouwens ook begrijpen dat de kernel bijna nooit "draait", alleen tijdens boot en syscalls. Dus zelfs al maak je de kernel 1000% sneller dan nog zal je in het dagelijks leven weinig verschil zien.

Dingen zoals de ZEN kernel kunnen wel echt een verschil maken, is misschien ook wel eens leuk om naar te kijken.