# Was bewirkt Kernel-Auswahl der richtigen Prozessorfamilie

## Randy Andy

Hallo Leute, ich hab da mal ne Frage...

Gestern beim gemütlichen Teil nach'm User-Group Treffen, meinte jemand mit deutlich mehr Linux-Erfahrung als ich (auch beruflich, aber halt Debian), dass die Kernel-Optimierung bezüglich der Selektion der Prozessor-Familie so gut wie nix bringen würde (nach dem Motto: die paar Milisekunden), nur geringe Codeänderungen zur Folge hätte, und eh nur zwei verschiedene Settings dann nicht an den gcc weiterreichen würde.

Auch ging es nicht um andere Kernelsettings wie SMP, Scheduler, oder sonstiges, sondern  nur um den Vergleich von 

x86 [ ] Generic x86 support eingeschaltet, oder aus, und stattdessen präzise Selektion des verwendeten Prozzis.

Hier ging es auch nicht um die Optimierungsoptionen auf Paketebene. Hier war er durchaus der Meinung dass diese hier (im Userspace) am meisten bringen würden, und daher durchaus ihre Berechtigung haben könten.

Nun kenne ich zwar ne ganze Menge Benchmarks, die die Geschwindigkeit der unterschiedlichen gcc Optimierungsstufen auf Paketebene miteinander vergleichen, aber zu oben angesprochenen unterschiedlichen Kernel-Optimierungen. Im Gegenteil, um die Ergebnisse dadurch nicht zu verfälschen, sind i.d.R. die kernel gleichermaßen konfiguriert, wenn es um den Vergleich der gcc Paketoptimierungen geht.

Auch frage ich mich, wie das Zusammenspiel der Programme die z.B. mit sse3 kompiliert wurden, mit dem generischen kernel der diese Optionen abgeschaltet hat abläuft, auch wenn der Prozessor sse3 unterstützen würde. 

Denn wenn die Programme für diese Beispiel (sse3),  den entsprechenden Befehlssatz des Prozzi nicht ansprechen können, weil der kernel sie an den Prozzi nicht durchreichen kann, dann würden doch einige Applikationen deutlich langsamer ablaufen (ffmpeg zum recoden von großen Videodateien). 

Oder hab ich da was falsch verstanden, und die Programme sprechen den Befehlssatz quasi am kernel vorbei trotzdem an?

Für mich macht der Aufwand der Optimierung jedenfalls am meisten Sinn, wenn die Kette durchgängig ist, und ich alles "optimal" auf meine vorhandene Hardware abstimme, oder garnicht.

Deshalb halte ich auch weiter daran fest, und somit auch an Gentoo!

Natürlich ist mir klar dass der Aufwand für Admins großer unterschiedlicher Serverlandschaften overkill ist. Aber dass es nix bringen würde mag ich auch nicht glauben. 

Ob's lohnt muss ja bekanntlich jeder für sich selbst entscheiden. 

Trotzdem lechzt mein Geist nach mehr Fakten, natürlich auch als Argumentationshilfe   :Wink: 

Hab Google, Wikipedia, Befehlssätze, gcc, kernel schon befragt, aber das geht scheinbar etwas tiefer. 

Und die Kernel-Mailingliste hab ich leider noch nicht abonniert oder seit Jahren verfolgt um hier besser Beschid zu wissen, also erleuchtet mich bitte!

Kernel-Hacker an die Front  :Laughing: 

Hier noch ein paar Links zu Benchmarks von denen ich sprach:

http://snaprails.tumblr.com/post/306663818/linux-performance-benchmark-system

http://snaprails.tumblr.com/post/325624962/linux-performance-benchmark-apache-nginx

http://global.phoronix-test-suite.com/?k=profile&u=unlotto-26045-5690-24680

http://www.linux-mag.com/id/7574

http://www.zdnet.de/anwendungsentwicklung_sse4_wann_bringt_es_wirklich_mehr_speed_story-20000201-39159310-1.htm

Mit wissensdurstigen Grüßen,

Andy.

----------

## Treborius

 *Randy Andy wrote:*   

> 
> 
> Auch frage ich mich, wie das Zusammenspiel der Programme die z.B. mit sse3 kompiliert wurden, mit dem generischen kernel der diese Optionen abgeschaltet hat abläuft, auch wenn der Prozessor sse3 unterstützen würde. 
> 
> Denn wenn die Programme für diese Beispiel (sse3),  den entsprechenden Befehlssatz des Prozzi nicht ansprechen können, weil der kernel sie an den Prozzi nicht durchreichen kann, dann würden doch einige Applikationen deutlich langsamer ablaufen (ffmpeg zum recoden von großen Videodateien). 
> ...

 

nagel mich nicht drauf fest aber ich denke das es eigentlich nur 2 arten von zugriffen auf das system gibt, die man zwangsläufig über den kernel machen muss

1. zugriffe auf den hauptspeicher (man kann nicht direkt vom processor speicher anfordern)

2. zugriffe auf geräte (darunter zählt auch die festplatte)

damit ist das system eigentlich durch den kernel völlig abgesichert,

denn ich kann das system nicht korrumpieren wenn ich keinen direkten schreibzugriff auf die festplatte habe, und auch nicht

wenn der kernel den hauptspeicher verwaltet

alles andere wird direkt auf dem processor verarbeitet (kein durchreichen über funktionen im kernel)

natürlich liefert der kernel noch viele andere funktionen (siehe zB framebuffer) die muss ich als programmierer aber nicht nutzen

nur ein kurzes beispiel :

ffmpeg wird normalerweise mit sse3 übersetzt (explizites angeben des compiler-flags)

würde sse3 durch den kernel gereicht werden, wäre ein angeben des flags sinnlos,

denn dann würde einfach der kernel entscheiden, was er mit den sse3 functionen macht

- entweder an den processor weiterreichen, oder emulieren

aber genau weiss ich das auch nicht, sse3 macht für mich der gcc  :Laughing: 

----------

## Treborius

will sich niemand an der diskussion beteiligen?

ich habe von den tieferen vorgängen nämlich auch nicht so wirklich ahnung.

ich bin c++ programmierer und in einer "höheren" programmiersprache kommt man 

mit assembler nicht wirklich in berührung.

Es wäre mir aber wichtig zu wissen, wie der compiler sowas wie sse und auch openmp umsetzt.

Grüsse Treb

----------

## 69719

Hier habt ihr noch was zum lesen.

P.S. Mit Auswahl der Prozessor Familie wird -march gesetzt.

----------

## Randy Andy

Hi Stefan,

das kannte ich schon, und daraus sowie den weiterführenden Links, ging die Antwort auf meine Fragen nicht wirklich hervor.

Dein P.S. deutet auch nur rudimentär darauf hin.

Ich bin auch etwas über die magere Beteiligung auf hohen Niveau enttäuscht, genau wie Treborius. 

Daher hab ich selbst so einiges recherchiert, es wurde aber nie so richtig konkret, daher muss ich einiges hinein interpretieren, allso korrigiert mich bitte, wenn ihr's definitv besser wisst.

Nachfolgend im quoting genannt sind Hilfstexte aus der kernel.config.

Ich hab ja schon lange keinen jungfräulichen, also nicht optimierten kernel mehr in den Fingern gehabt, aber anscheinend ist das die deault Einstellung, wenn keine Prozessorarch selektiert wurde:

 *Quote:*   

> 
> 
> prompt "Processor family"
> 
> default M686 if X86_32
> ...

 

demnach käme bei 32-bit Prozzis diese Einstellung zum tragen:

 *Quote:*   

> 
> 
> config M686
> 
> bool "Pentium-Pro"
> ...

 

bei 64-bit'ern demnach diese:

 *Quote:*   

> 
> 
> config GENERIC_CPU
> 
> bool "Generic-x86-64"
> ...

 

und als typischer generischer Distributionskernel dann noch diese:

 *Quote:*   

> 
> 
> config X86_GENERIC
> 
> bool "Generic x86 support"
> ...

 

Hier wäre allerdings meine Frage welche generischen Optimierungen hier konkret gesetzt würden. ich vermute hier handelt es sich nur um den kleinsten gemeinamen Nenner. 

Oder werden hier alle Befehlssätze die's gibt unterstützt, so dass der kernel maximal davon profitieren kann, so er diese Funktion denn implementiert hat, daher stammt dann eventuell der häuftig zu lesende Hinweis dass der kernel-code dadurch um ein paar kb größer wird.

Wenn man dann stattdessen einen konkreten Prozessor selektiert, dann werden also seine speziellen, ggf. zusätzlichen Befehlsregister gesetzt /aktiviert, und diese beim kompilieren des kernels als optionen an den gcc übergeben, z.B.:

 *Quote:*   

> 
> 
> config MK7
> 
> bool "Athlon/Duron/K7"
> ...

 

Die Auswirkung hängen wohl auch stark vom entsprechenden Prozessor ab, und die Umsetzung der entsprechenden Flags von der Aktualität der verwendetetn gcc-Version. Daher dieser Hinweis:

 *Quote:*   

> 
> 
> config MATOM
> 
> bool "Intel Atom"
> ...

 

Hinzu kommt wohl, dass der kernel bei der Selektion des konkreten Prozzis erst über die dort verbauten cache-größen von L1 L2 (L3) caches  und andere Performance-Relevante Spielereien und Besonderheiten informiert wird, und diese maximal ausnutzen / berücksichtigen kann.

Was es unterm Strich bringt vermag ich mangels konkreter Benchmarks nicht zu sagen, aber klar ist für mich, dass wenn man alles richtig setzt, die Performance besser sein muss, als bei generischen Settings.

Zur Frage was mit Prozessorregistern in den Paketen passiert, die der kernel garnicht unterstützt kann ich nur mutmaßen, dass diese durch den Kernel abstrahiert werden, und entsprechend umgesetzt werden, auf Funktionen die der Prozzessor unterstützt. 

Diese anschauliche Schaubild verleitet mich zu dieser wagemutigen Interpretation, gepaart mit meinen Recherchern.

http://de.wikipedia.org/w/index.php?title=Datei:Linux_Kernel_Stuktur.svg&filetimestamp=20091107100810

Wie gesagt, wer's besser weiss, oder vernünftig erklären kann, oder über gute Quellen verfügt, immer her damit.

Informativen Gruß, Andy.

----------

## Veldrin

Hallo zusammen,

Andy hat mich auf diesen Thread aufmerksam gemacht, als ich eine etwas gewagte Aussage betreffend Optimierungen im Kernel gemacht habe.

Wie escor schon richtig bemerkt hat, wird mit der Prozessor Option eine -march flag gesetzt. Diese fällt in der Regel weniger aggressiv aus, als wenn sie in der make.conf gesetzt wird. 

Die hat folgenden Hintergrund: Der Kernel ist das Zentral Stück Software im einem OS. als zentrales Element sollte Stabilität Vorrang vor irgendwelchen geschwindigkeitsrelevanten Optimierungen haben. Erganzend muss ich gestehen, dass seit dem i686 (resp dem generischen x86_64) keine Kernel relevanten optimierungen mehr in die Instruction Sets aufgenommen wurden. Alle Befehlserweiterungen zielen auf Parallelverarbeitung (SIMD = Single Instruction Multiple Data, Vectorization) und Floatingpoint Optimierung ab welche mehrheitlich in Multimedialen und wissenschaftlichen Anwendungen zu finden sind (stichwort Vektor/Matrixrechnung)

Dazu kommt, dass ein Programm welches nicht auf den Prozessor opimiert wurde, zwingendermassen schlechter läuft, es bedeutet nur, dass nicht alle vom Prozessor unterstützten Features angewendet werden können, was sich aber teilweise einem Geschwindigkeitsnachteil äussert.

Anbei noch ein Auszug aus dem Kernel sourcecode, welche die einzelnen Optiomierungen anzeigt. 

```
linux-2.6.35.7/arch/x86$ grep march Makefile*

Makefile:        cflags-$(CONFIG_MK8) += $(call cc-option,-march=k8)

Makefile:        cflags-$(CONFIG_MPSC) += $(call cc-option,-march=nocona)

Makefile:                $(call cc-option,-march=core2,$(call cc-option,-mtune=generic))

Makefile:       cflags-$(CONFIG_MATOM) += $(call cc-option,-march=atom) \

Makefile_32.cpu:cflags-$(CONFIG_M386)           += -march=i386

Makefile_32.cpu:cflags-$(CONFIG_M486)           += -march=i486

Makefile_32.cpu:cflags-$(CONFIG_M586)           += -march=i586

Makefile_32.cpu:cflags-$(CONFIG_M586TSC)        += -march=i586

Makefile_32.cpu:cflags-$(CONFIG_M586MMX)        += -march=pentium-mmx

Makefile_32.cpu:cflags-$(CONFIG_M686)           += -march=i686

Makefile_32.cpu:cflags-$(CONFIG_MPENTIUMII)     += -march=i686 $(call tune,pentium2)

Makefile_32.cpu:cflags-$(CONFIG_MPENTIUMIII)    += -march=i686 $(call tune,pentium3)

Makefile_32.cpu:cflags-$(CONFIG_MPENTIUMM)      += -march=i686 $(call tune,pentium3)

Makefile_32.cpu:cflags-$(CONFIG_MPENTIUM4)      += -march=i686 $(call tune,pentium4)

Makefile_32.cpu:cflags-$(CONFIG_MK6)            += -march=k6

Makefile_32.cpu:# Please note, that patches that add -march=athlon-xp and friends are pointless.

Makefile_32.cpu:cflags-$(CONFIG_MK7)            += -march=athlon

Makefile_32.cpu:cflags-$(CONFIG_MK8)            += $(call cc-option,-march=k8,-march=athlon)

Makefile_32.cpu:cflags-$(CONFIG_MCRUSOE)        += -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0

Makefile_32.cpu:cflags-$(CONFIG_MEFFICEON)      += -march=i686 $(call tune,pentium3) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0

Makefile_32.cpu:cflags-$(CONFIG_MWINCHIPC6)     += $(call cc-option,-march=winchip-c6,-march=i586)

Makefile_32.cpu:cflags-$(CONFIG_MWINCHIP3D)     += $(call cc-option,-march=winchip2,-march=i586)

Makefile_32.cpu:cflags-$(CONFIG_MCYRIXIII)      += $(call cc-option,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0

Makefile_32.cpu:cflags-$(CONFIG_MVIAC3_2)       += $(call cc-option,-march=c3-2,-march=i686)

Makefile_32.cpu:cflags-$(CONFIG_MVIAC7)         += -march=i686

Makefile_32.cpu:cflags-$(CONFIG_MCORE2)         += -march=i686 $(call tune,core2)

Makefile_32.cpu:cflags-$(CONFIG_MATOM)          += $(call cc-option,-march=atom,$(call cc-option,-march=core2,-march=i686)) \

Makefile_32.cpu:cflags-$(CONFIG_X86_ELAN)       += -march=i486

Makefile_32.cpu:cflags-$(CONFIG_MGEODEGX1)      += -march=pentium-mmx

Makefile_32.cpu:cflags-$(CONFIG_MGEODE_LX)      += $(call cc-option,-march=geode,-march=pentium-mmx)
```

cheers

V.

Vorgäng bitte ich um Entschuldigung für alle Typos und meine katastrophales Denglish (oder NeuDeutsch) - ich schreib nicht sehr oft in deutsch im Forum.Last edited by Veldrin on Thu Sep 30, 2010 6:56 am; edited 1 time in total

----------

## Randy Andy

Hallo Veldrin.

Zuerst einmal vielen Dank, dass du meiner Bitte nachgekommen bist, und für deine ausführliche Antwort.

Das hat schonmal für noch mehr Klarheit gesorgt, und etwas tiefere Einblicke in die Funktionsweise eröffnet.

Deine u.a. Kernaussage verwirt mich jedoch jetzt, und ich vermute dass ist lediglich auf einen kleinen, aber entscheidenden Formulierungsfehler zurückzuführen, der die Bedeutung (und meine Erwartung) ins Gegenteil verkert.

 *Quote:*   

> 
> 
> Dazu kommt, dass ein Programm welches nicht auf den Prozessor opimiert wurde, zwingendermassen schlechter läuft, es bedeutet nur, dass nicht alle vom Prozessor unterstützten Features angewendet werden können, was sich aber oft einem Geschwindigkeitsvorteil äussert. 
> 
> 

 

Müsste es nicht z.B. so heissen?

Dazu kommt, dass ein Programm welches nicht auf den Prozessor opimiert wurde, nicht zwingendermassen schlechter läuft, es bedeutet nur, dass nicht alle vom Prozessor unterstützten Features angewendet werden können, was sich aber oft in einem Geschwindigkeitsnachteil äussert. 

Gehst du mit dieser Aussage konform, und ist klar was ich damit zum Ausdruck bringen möchte?

Dann würden wir gänzlich übereinstimmen, und ich könnte endlich wieder beruhigt schlafen   :Wink: 

P.S. Ich wollte mein englisch wäre auch nur ansatzweise so gut wie dein deutsch, von französich ganz zu schweigen, für den Fall dass du das auch noch sprichst. 

Das ist also kein Grund oder Hindernis sich nicht auch mal im deutschen Forum zu tummeln, jedenfalls keins für dass du dich schämen müsstest.   :Wink: 

Also bitte versteh das nicht als Belehrung, passiert mir auch recht häufig wenn ich mich in meinen Schachtelsätzen verschachtele  :Laughing: 

Mit bestem Gruß,

Andy.

----------

## Veldrin

full ack - fragt bitte noch was ich mir dabei gedacht habe....   :Embarassed: 

(und korrigiert)

 *Quote:*   

> Also bitte versteh das nicht als Belehrung, passiert mir auch recht häufig wenn ich mich in meinen Schachtelsätzen verschachtele

 

Hab ich auch nicht so verstanden - passiert (fast) jedem, vor allem wenn ich einen Satz 3x überarbeitet habe.

Oder wies im Englishen heisst: No Offence taken.

Ich muss meine Suchoptionen mal einstellen, damit ich das deutsche Subforum auch erwische...

----------

## Randy Andy

Alles klar Veldrin.

Danke für die prompte Antwort, und dass du's nicht in den falschen Hals gekriegt hast.

Würde mich freuen dich auch gelegentlich hier anzutreffen.

Bis dahin,

alles Gute.

Andy.

----------

