knasan

Linux and more

Archiv für das Schlagwort “x86 processors”

hard-masked USE-Flags

Ich bin schön des öfteren darauf gestoßen dass die USE-Fags 3dnow, 3dnowext, sse, sse2 und sogar vdpau hard-masked sind.
Warum das so ist, wusste ich bisher nicht. Heute bin ich zufällig auf eine Seite gestoßen warum 3dnow, 3dnowext, sse und sse2 maskiert sind.

Ursprünglich wurden die USE-Flags eingeführt, um die Unterstützung für ältere Prozessoren wie der Pentium I, der nichts mit diesen Flags anfangen kann, zu emulieren.
Derzeit unterstützen alle AMD64s die gleiche Kombination von erweiterten Befehlssätze, so gibt es keinen Grund zur Verwendung der genannten USE-Flags.
Deshalb sind diese USE-Flags hart maskiert in allen AMD64-Profilen.

Es bedeutet jedoch nicht das diese nicht verwendet werden können, man kann diese USE-Flags hart einschalten. Die Frage lautet nun, benötigt man diese?
Was sind die Vor bzw. Nachteile, darauf wird leider nicht eingegangen, es ist nur beschrieben warum diese Maskiert sind. Aber immer hin, nun kenne ich den Grund.

Assembler Optimisation

Modern x86 processors support special instruction sets like mmx, sse, SSE2 and 3DNow!. AMD64 also provides support for them, but in most cases, x86 assembler code is incompatible with AMD64 assembler. There are lots of packages that provide support through USE flags for these instruction sets. Originally, the USE flags were introduced to keep support for older processors such as the Pentium I that can’t handle such code. Currently, all AMD64s support the same combination of extended instruction sets, so there is no reason to make use of the mentioned USE flags. That’s why these USE flags are hard-masked in all AMD64-profiles. This doesn’t mean we don’t support the extensions themselves, instead, we hard-enable them.

The following USE flags are masked on AMD64:

mmx
mmx2
sse
sse2
3dnow
3dnowext

Quelle: http://devmanual.gentoo.org/archs/amd64/index.html

Es gibt zur Zeit vieles was ich an den USE-Flags nicht verstehe und hoffe das ich darüber mehr Informationen sammeln kann. Leider sind die Aussagen wie „X – Support for X11“ wenig aussage kräftig und es zum Beispiel um opengl geht. „opengl, gles1 und geles2“ Laut google gibt es schon gles3. Heißt es nun wenn man gles2 setzt kein gles3 bekommt? Ein USE-Flag für gles3 gibt es gar nicht – ist es der Standard? All solche dinge kosten oft etwas Zeit und diese Aufgabe werde ich mich demnächst kümmern und hier veröffentlichen.

http://www.khronos.org/opengles/

Da diese USE-Flags etwas mit Tuning zu tun haben, möchte ich nun wirklich etwas Zeigen was getuned ist.
In mein System sind zwei SSD, eine für mein HOME und die andere mein System. Zum Kompilieren verwende ich „ccache“ und meine MAKEOPTS ist auf „-j8“ gestellt.
Getestet habe ich libreoffice, was normal ca 60 Minuten dauert (etwas mehr oder weniger). Mit aktivem ccache und MAKEOPTS -j8, wenn libreoffice schon im cache liegt, dauert es nur noch 14 Minuten.
Aber was Passiert wenn man den Scheduler ändert? Auf diese Idee bin ich gekommen, da ich gelesen habe dass man für SSDs den Scheduler auf „noop“ setzen sollte. Hier die Resultate mit time gemessen.

cfg
real 14m11.091s
user 20m37.011s
sys 7m59.036s

noop
real 12m36.266s
user 19m59.285s
sys 7m33.866s

deadline
real 12m40.719s
user 20m2.532s
sys 7m36.524s

Es gibt derzeit diese drei Scheduler, cfg, noop und deadline. Der Scheduler kann während des betrieb gewechselt werden, dieser überlebt jedoch keinen Neustart des Systems.
Da der Scheduler in /sys/block/FESTPLATTE/queue/schedule gesetzt werden muss, kann dieser nicht in sysctl.conf gesetzt werden, sysctl ist nur dafür ausgelegt das /proc zu ändern.
Möchte man den Scheduler seiner Wahl beim hochfahren aktivieren gibt es drei Möglichkeiten.

1. Man schreibt sich ein eigenes Init Skript (schlechte idee)
2. Man kompiliert einfach den Kernel so, dass der Standard Scheduler nicht „cfq“ sondern ein anderer ist. Machbar, kostet aber mehr Zeit. Diese IDEE ist aber nur bedingt schlecht, denn manche Scheduler sind für Datenbank-Zugriff besser geeignet und könnte auf einem Server durchaus Sinn machen.
3. Man verwendet ein Bash Script (was kein init Skript ist) der einfach per echo den Scheduler beim hochfahren des Rechners setzt. Hierfür gibt es in Gentoo/Funtoo das Verzeichnis /etc/local.d.

Einfach diesen Code in einer Datei Speichern unter /etc/local.d und ausführbar machen. Schon hat man seinen Scheduler seiner Wahl per Default 🙂

#!/bin/sh
echo noop > /sys/block/sda/queue/scheduler
echo noop > /sys/block/sdb/queue/scheduler

Es kommt auch mal vor, das ein anderer Scheduler benötigt wird. Auch hierfür gibt es eine einfache Lösung.
Dieses Script nach /usr/local/sbin Speichern, ich nannte es switch_scheduler.

#!/bin/sh

if [ -z $1 ]; then
echo "cfq, noop or deadline"
exit
fi

echo $1 > /sys/block/sda/queue/scheduler
echo $1 > /sys/block/sdb/queue/scheduler

Als Root, ist es nun ganz einfach Möglich auf einen anderen Scheduler zu wechseln. Dieses Script ist natürlich total dumm, da nicht geprüft wird ob es den angegeben Scheduler überhaupt existiert.
Es ist durchaus denkbar, einen Schuduler aus dem Kernel zu werfen und somit existiert diese nicht. Auf einer komplexen überprüfung habe ich auch verzichtet, da nun der Scheduler geschrieben werden kann, der auch existiert.

Welche Scheduler das System unterstütz bekommt man mit cat raus.

cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

Der zur Zeit verwendete Scheduler wird hier in eckigen Klammern gelistet.

Wird der Scheduler nicht vom System unterstützt bekommt man eine Fehlermeldung, ansonsten passiert nichts

sudo switch_scheduler hallo
/usr/local/sbin/switch_scheduler: line 8: echo: write error: Invalid argument
/usr/local/sbin/switch_scheduler: line 9: echo: write error: Invalid argument

Oder auf Deutsch

udo switch_scheduler hallo
/usr/local/sbin/switch_scheduler: Zeile 8: echo: Schreibfehler: Das Argument ist ungültig.
/usr/local/sbin/switch_scheduler: Zeile 9: echo: Schreibfehler: Das Argument ist ungültig.

Es kann sich also lohnen, mal zu testen wie sich die Scheduler im Alltag verhalten. Beim Kompilieren hat eindeutig noop bei mir gewonnen.
Diesen habe ich auch mal auf Default gesetzt. Selbst beim Spiel stuntrally merke ich keinen unterschied. Dies kann aber an meiner SSDs zusammen hängen.
Wenn ich denke, hm ist irgendwie langsam, wechsel ich zu cfq, dieser ist in der Regel der Default Scheduler.

Viel Spaß beim Testen.

knasan

Advertisements

Beitragsnavigation

%d Bloggern gefällt das: