Kernel Tuning[/b]
Na, wenn ich schon von Linux Tuning anfange, dann sollte ich vieleicht auch mal so genau sein und verraten was man am "wirklichen Linux" sprich dem Kernel so machen kann.
Am Kernel lassen sich auch so die ein oder anderen Dinger drehen, wobei ich hier jetzt nur auf die gröbsten eingehen kann. Nicht nur weil alle Details den Rahmen und auch mein Wissen sprängen würden, sondern auch weil die meisten letzten feintuning Ma?nahmen wirklich von dem jeweiligen System und Verwendungszweck abhängen und da kann ich schlecht orakeln.
Aber soweit so gut, einiges nützlich hab ich schon anzubieten
Als erstes braucht man erst einmal die Kernel Sourcen.
Es gibt hierbei entweder die Möglichkeit die Sourcen des Distributions eigenen Kernels zu verwenden oder die von Kernel.org .
Der Unterschied liegt darin, das die Kernel von kernel.org so genannte "vanilla" Kernel sind, wärend die Distributions spezifischen Sourcen von dem jeweiligen Distributor verändert bzw. gepatcht werden.
So ein Distributions eigener Kernel kann schon mal um die 300 Änderungen gegenüber dem ursprünglichen vanilla Kernel von Kernel.org aufweisen.
Das heißt jetzt was?
Also, zB. hat der SuSE Kernel einen Support für ReiserFS4.
Im vanilla Kernel von Kernel.org ist dieser Support nicht mit drinn, weil ReiserFS4 nach Auffasung der Kernel Entwickler noch nicht stabil genung ist.
Ob der Support jetzt stabil ist oder nicht, darum geht es jetzt nicht. Es geht darum, das die Funktionen und das verhalten des Kernels unterschiedlich sein können.
Wenn es jetzt um den Bau eines eigenen Kernels geht, würde ich empfehlen die Sourcen von Kerenel.org zu verwenden. Erstens weil es zu Problemen kommen kann, einen bereits vom Distributor stark veränderten Kernel nach eigenen Vorstellungen weiter zu verändern und ausserdem geht es ja darum einen "eigenen" Kernel zu bauen, keinen vorgekauten.
Warum ezähl ich das jetzt alles? Hätte ich doch gleich sagen können, zieht euch den Kernel von Kernel.org . Der Grund ist, das wenn man jetzt zum Beispiel SuSE mit ReiserFS4 benutzt und dann einen Kernel aus den Sourcen von Kernel.org baut, dieser neue Kernel kein ReiserFS4 mehr versteht. Das würde dann ziemlich blöd laufen. Deshalb muss man sich im zweifels Fall am besten vorher Informieren was das aktuelle System kann bzw. welche Funktionen eventuell benötigt werden, den der vanilla Kernel von Kernel.org vieleicht nicht hat. Diese fehlenden Funktionen muss man dem Kernel dann noch selbst hin zu fügen, sprich den Kernel patchen.
So, jetzt geht es erst einmal los.
Lader euch also am besten die aktuellen Kernel Sourcen von Kernel.org runter, wobei man eventuell darauf achten sollte, das benötigte Patches oder auch Treiber für diese Kernel Version verfügbar sind.
Die Kernel Sourcen werden im Verzeichnis /usr/src entpackt. Also
# tar xvzf linux-image-2.6.xx.tar.gz
oder mit tar xvjf wenn man die .bz2 version genommen hat.
( für Faule ist
unp übrigens immer ein guter Tip
)
danach sollte man einen symbolischen Link erstellen.
# ln -s linux linux-image-2.6.xx
Der Grund ist, das die Sourcen in der Regel in dem Verzeichnis /usr/src/linux erwartet werden.
Danach wechselt man in das Verzeichnis mit
# cd /usr/src/linux
So, bevor es jetzt an die Konfiguration geht, ist es Zeit die Kernel sourcen anzupassen (wenn man das dann möchte). Im Kernel nicht vorgesehene Funktionen oder welche die man ändern möchte, müssen in den Kernel gepatcht werden.
Es heißt also die Patches zu besorgen, die man gerne haben möchte.
Damit es etwas einfacher ist, man nicht alles einzeln machen muss, gibt es so genannte "Patch-Sets" welche eine Samlung von Patches sind.
Zum Beispiel gibt es in der Regel auch vom jeweiligen Distributor ein Patch-Set.
Wo es ja hier aber um Tuning geht und um ein bisschen Performec, möchte ich an dieser Stelle das Patch-Set von Con Kolivas empfehlen.
Dieses Patch-Set ist meiner Meinung nach eines der besten und auch gerade für diesen Zweck vor gesehen. Ich werde es deshalb auch als Beispiel verwenden.
Man sollte sich also das zur Kernel Version passende Patch-Set (oder den patch) runter laden.
Von Con Kolivas gibt es zwei Versionen, einmal für Desktop PCs und einmal für Server.
Den Patch würde man dann mit
# patch -p1 < Pfad_bzw._Name_des_Patch.patch
einspielen.
Wenn man seinen Kernel so gepatch hat, wie man es gerne möchte, geht es an die Konfiguration.
Wer möchte kann als Anhalt für die neue Konfiguration die aktuelle verwenden.
Die Aktuelle befindet sich in der Regel im Verzeichnis /boot und trägt einen Namen wie vmlinuz-2.6.xx.config. Damit diese Konfigurationsdatei verwendet werden kann, kopiert man sie ins aktuelle Verzeichnis unter den Namen .config
# cp /boot/vmlinuz-2.6.xx.config .config
Wer diese Konfiguration Nahtlos übernehmen will, kann dieses mit
# make oldconfig
machen. Ich rate aber dazu wenigstens die Prozessor Optimierung anzupassen.
Für eine individuelle Konfiguration sollte man
menuconfig verwenden oder auch
xconfig. (ich finde menuconfig am besten).
# make menuconfig
In dem Beispiel bekommt man ein
ncurses basiertes Konfigurations Menü.
Der wichtigste Schritt ist hier auf jeden Fall das Anpassen an den Prozessor.
Natürlich läuft auch ein bis zum i386 abwärts compiliertes Kernel auf einem Athlon Prozessor, aber dadurch würde der gute Athlon nur wie ein sehr sehr schneller 386er laufen und alle Fähigkeiten die er diesem gegenüber hat würden nicht berücksichtigt werden.
Also Prozessor auswählen.
Processor type and features >
Processor family >
Athlon/Duron/K7 (oder was auch immer)
So, alle anderen Einstellungen muss fast jeder selber vornehmen.
Ich kenne eure Hardware nicht.
Wer die Konfiguration des Aktuellen Kernels als Grundlage genommen hat, der wird so zumindest schon mal vermutlich einen lauffähigen Kernel bekommen.
Wer seine Kernel Sourcen mit speziellen Patches versehen hat, sollte diese natürlich auch aktivieren.
Mit "exit" geht es wieder raus, jetzt muss der Kernel nur noch gebaut werden.
( Debianer siehe unten )
Als erstes sollte man immer ein
# make clean
aufruffen. Damit werden Reste eines eventuell schon vorherigen Versuch bereinigt.
Damit der Kernel im Zweifelsfall nicht mit einer aktuellen Version mit gleicher Revisionsnummer kolidiert, sollte man dem Namen eine eigene Erweiterung verpassen. Dazu öffnet man mit einem Editor ( wo wir schon auf der Konsole sind empfehle ich
nano denn der gute
vi ist kein Zuckerschlecken ) das
Makefile und fügt bei "EXTRAVERSION =" eine beliebige Bezeichnung ein.
Mit
# make dep
werden dann die Abhängigkeiten geklärt und
# make bzImage
erstellt dann ein Kernel Image.
Um dieses verwenden zu können, muss man das gerade erstellte Image noch nach /boot kopieren und am besten sinnvoll umbenennen.
# cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.xx-"die persönliche vergebene Bezeichnung"
Wer das ganze nicht für einen PC baut, der muss natürlich arch/xxx anpassen.
Wer sich für einen Kernel mit Modulen entschieden hat, was in der Regel der Fall ist, der muss jetzt noch die Module erzeugen
# make modules
und installieren mit
# make modules_install
So, nach dem der Kernel jetzt gebaut und die Module installiert sind, muss man nur noch den Bootloader anpassen. Bei den meisten Distributionen ist das wohl mitlerweile GRUB.
# nano /boot/grub menu.list
Man fügt dort einen neuen Eintag hinzu und sollte den für den alten Kernel aber noch keinesfalls entfernen. Kann ja immer sein, das was daneben gegangen ist.
Gut abgucken kann man aber schon bei dem Eintrag des aktuellen Kernels, am besten übernimmt man das erst einmal alles so und ändert nur den Namen des kernels entsprechend ab.
Neu booten und hoffen
Für Debianerwer Debian benutzt oder eine Distribution die auf Debian aufbaut (zB. Ubuntu ) der kann das alles etwas bequemer haben.
Letztendlich sind nur alle Schritte bis zur Konfiguration nötig, den Rest erledigt
kpkg ( dafür muss aber kernel-package installiert sein )
Man braucht dann nur einen Befehl und der Clou bei der Sache ist, es wird ein .deb Paket erzeugt, welches normal wie jedes andere Paket verwaltet werden kann.
# make-kpkg kernel_image
baut dieses Paket. zu finden ist es dann im absteigenden Verzeichnis also /usr/src .
Auch kpkg können noch weitere Optionen übergeben werden. zB. --initrd für eine Ramdisk oder --revision= für eine Persönlich Bezeichnung (siehe oben).
Nebenbei wird bei der Installation des fertigen Kernel Paketes GRUB bzw. LiLo gleich automatisch angepasst.
für die kleinenWer einen etwas betagten Rechner hat, der sollte anstelle des 2.6er Kernel lieber eine aktuelle 2.4 Version verwenden.
Der 2.4 Kernel wird immer noch aktiv weiter entwickelt, bekommt also auch noch weiterhin Sicherheits und Buckfixes, ist aber erstens kleiner und verbraucht auch weniger Resourcen.
Wer es noch etwas sparsammer haben möchte, der kann den kernel auch statisch ohne Module bauen. Dadurch wird der Kernel wesentlich kleiner zB. nur 1MB anstelle von 30MB. Ausserdem merkt man auf alter Hardware schon noch den unterschied zwischen einkompilierten Treibern und denen als Modul.
Welche Module das System braucht, welche also in den Kernel müssten erfährt man durch den aufruf von
lsmod.
Wenn es nur um die größe geht, zum Beispiel um einen Kernel auf eine Diskette zu bekommen oder weil die alte Notebook Festplatte wirklich nichts anderes mehr zu läst, der sollte seinen Kernel nicht auf einen Prozessor obtimieren bzw. nur auf 386 setzen. Der geschwindigkeitsvorteil von der Prozessor Optimierung entsteht auch daraus, das die Bits so verteielt werden, das sie von dem Prozessor Typ am schnellsten verarbeitet werden können. Das entspricht aber oft nicht der efizientesten Platz Nutzung.
So....
Meldet euch bei Unklarheiten oder wenn das alles gar nicht will bei mir.
Achja, falls irgendwas hängt.
Vieleicht fehlt eine dieser Sachen auf dem Rechner:
GCC, make, patch, ncurses
Wer den gcc4.0 nutzt und Probleme beim kompilieren einer älteren Kernel Version hat, der sollte lieber den gcc3.4 verwenden. Beide können parallel auf dem System laufen (eventuell den link von gcc anpassen).
Thema: Linux Tuning (Gelesen 4067 mal)