Linux kernel tweaking/slipstreamen

[MarcHeijerman]

Hi all

ben me wat meer aan het verdiepen in het tweaken en slipstreamen van een Linus kernel. Heb nu de laatste stable versie gedownload (3.2.11)

Momenteel ben ik met Debian aan het spelen. Dus zijn de commands iets afwijken dan van een RedHad based distro, maar ik kernel config maken blijft uiteraard hetzelfde.

Nu kan je in je Makefile je kernel een extra version meegeven, in mijn geval:

code:

VERSION = 3
PATCHLEVEL = 2
EXTRAVERSION =  -`hostname`-ext4-btrfs-only
NAME = Saber-toothed Squirrel  (Mint Debian based ding denk ik...)

Wanneer ik de config ga aanpassen:

code:

make clean && make mrproper;cp /boot/config`uname -r` . ;make menuconfig

Zijn er uiteraard een hoop opties aan te passen. Nu maak ik alleen gebruik van ext4 en wil mischien btrfs gaan uitproberen, dus heb ik ext2, ext3, xfs, reiserfs uitgeschakeld.

Nu vraag ik mij af wat er nog meer te tunen valt tijdens de config. Ik zie bijvoorbeeld veel amd chipset opties terwijl ik Intel gebruik, op de videokaart na. In hoeverre kan ik de amd chipset opties dus uitschakelen.

Ik zie bij het aantal cpu's standaard 512 staan, ik heb er 4 + hyperthreading = 8, kan ik dit dus naar 8 terugdraaien?
enz.

Ook zie ik veel hardware configs voor MAC en andere HID devices die ik niet gebruik, kan ik deze ook domweg uitschakelen ?

Verder vraag ik me af of het zin heeft en of effect heeft om de default scheduler (CPU) op performance te zetten ipv ondemand.

En zo zijn er vast nog vele tips en trucs die het compilen van een kernel meer richten op de huide pc/server.

Mischien kunnen we die tips en trucs met elkaar delen.

[Verwijderd]

De beste tip die ik je kan geven is: probeer het.
Wat kan er allemaal misgaan?

[Xudonax]

Van alle hardware die je niet hebt kun je de opties gewoon keihard uitzetten. Als je twijfelt kun je er altijd een module van maken. In het ergste geval start je nieuwe kernel niet (goed) op, en kun je terug naar je oude kernel (welke je natuurlijk niet overschijft/weggooit/uit je bootloader haalt) om het opnieuw te proberen.

De default scheduler zou ik niet aanpassen. Als je deze op performance zet draait je CPU altijd op maximale snelheid, ook als deze niets aan het doen is. Onnodig stroomgebruik dus

[MarcHeijerman]

Ok, geen performance scheduler dus , oude kernels blijven uiteraard in /boot voor het geval dat.

Zijn er nog andere tips om bijvoorbeeld je kernel meer te tweaken/tunen, gewoon coole dingen om uit te proberen ?

raid opties bijvoorbeeld, of ssd tweaks ?

[ Voor 9% gewijzigd door MarcHeijerman op 17-03-2012 12:45 ]

[Xudonax]

Zet je CPU goed in de configuratie, dan heb je al een heel stuk winst te pakken. Verder is het gewoon een kwestie van proberen. De laatste keer dat ik eraan heb lopen sleutelen was rond 2.6.30~2.6.38 voor mijn Eee PC. Maar ik heb niet echt meer een idee wat ik allemaal had gedaan toendertijd.

Het komt er in ieder geval op neer dat je zoveel mogelijk dingen die je niet hebt gewoon uitzet.

[Ertepeller]

Ik zie alvast een typo: het is "make mrproper" en niet "mroper".

Het staat voor "Mr. Proper", was/is een of andere mascotte van een schoonmaakmiddel geloof ik.

Als je uitgaat van de standaard Mint (Debian) configuratie dan zie je dat het gros van de opties modulair is.
Als je de betreffende hardware niet hebt wordt de module nooit geladen; haal je hem weg uit de config, dan word je kernel niet sneller oid, maar het scheelt wel compileertijd. Er zijn namelijk héél erg veel modules - het overgrote deel van de kernel source bestaat uit drivers.

Als je een SSD hebt, zou je bv de IO scheduler op deadline kunnen zetten; default staat ie op CFQ, maar die is meer gericht op 'ouderwetse' harde schijven.

[ Voor 62% gewijzigd door Ertepeller op 17-03-2012 13:00 ]

[MarcHeijerman]

Ertepeller schreef op zaterdag 17 maart 2012 @ 12:49:
Ik zie alvast een typo: het is "make mrproper" en niet "mroper".

Het staat voor "Mr. Proper", was/is een of andere mascotte van een schoonmaakmiddel geloof ik.

Ja klopt typo, sorry

[Ploink]

Als ik software zelf wil compileren, dan maak ik altijd eerst een eigen rpm package en dan installeer ik die. In fedora kun je de SPEC file aanpassen naar eigen wensen en dan een "rpmbuild -ba package.spec" doen.

Debian heeft net zoiets voor deb packages.
Het voordeel van deze werkwijze is dat je de boel met de package manager kan beheren.
Bovendien is er een berg aan distro-specifieke patches voor een kernel en die worden dan ook meteen meegenomen.

Het kan leuk zijn om te experimenteren met een eigen kernel, maar een moderne distro heeft vrijwel alles als module meegeleverd. Praktisch gezien zou ik nooit een eigen kernel bakken tenzij het echt niet anders kan.

[Ploink]

Compiling kernel - and packaging it the Debian way

[MarcHeijerman]

Ploink schreef op zaterdag 17 maart 2012 @ 13:03:
Compiling kernel - and packaging it the Debian way

Goede tip voor de basic compilation/installation

[Ploink]

Getting a Debian kernel source tree for driver compilation

Deze is grotendeels hetzelfde maar installeert een debian source package ipv een vanilla kernel.
Het kan zijn dat hier wel specifieke debian patches bij zitten. Fedora heeft de gewoonte om veel eigen patches toe te voegen, maar ik heb geen idee of Debian dat ook doet...

[Ertepeller]

Ploink schreef op zaterdag 17 maart 2012 @ 13:18:
Getting a Debian kernel source tree for driver compilation

Deze is grotendeels hetzelfde maar installeert een debian source package ipv een vanilla kernel.
Het kan zijn dat hier wel specifieke debian patches bij zitten. Fedora heeft de gewoonte om veel eigen patches toe te voegen, maar ik heb geen idee of Debian dat ook doet...

Jazeker: Debian kernel handbook: patches
Kernel patches zijn in de repo terug te vinden als linux-patch-debian-x.y:

code:

$ apt-cache pkgnames | grep linux-patch-debian-
linux-patch-debian-3.2
linux-patch-debian-3.3

1 ding ding wat me zo te binnen schiet is aufs - zit niet in de officële kernel, maar heb je wel nodig om een live-cd te kunnen draaien.

[MarcHeijerman]

Zijn er nog tips mbt SSD ?

[Ertepeller]

Wat ik al zei: IO scheduler op "deadline" zetten.

Lokatie: Enable the block layer -> IO Schedulers -> Default I/O Scheduler

[ Voor 44% gewijzigd door Ertepeller op 17-03-2012 15:08 ]

[Ploink]

De scheduler kun je ook achteraf nog wijzigen.
Linux Change The I/O Scheduler For A Hard Disk

[MarcHeijerman]

Ertepeller schreef op zaterdag 17 maart 2012 @ 15:05:
Wat ik al zei: IO scheduler op "deadline" zetten.

Lokatie: Enable the block layer -> IO Schedulers -> Default I/O Scheduler

Sorry even over heen gelezen, en wat doet dit precies, op deadline zetten ?
zoiets als:

na een i/o request die niet voltooid wordt, de request laten vervallen na een idle timer ?

[ Voor 14% gewijzigd door MarcHeijerman op 17-03-2012 15:36 ]

[Ploink]

CFLAGS optimaliseren voor jouw processor:
http://en.gentoo-wiki.com/wiki/Safe_Cflags
http://manpages.ubuntu.co...n1/dpkg-buildflags.1.html

[MarcHeijerman]

Ploink schreef op zaterdag 17 maart 2012 @ 15:41:
CFLAGS optimaliseren voor jouw processor:
http://en.gentoo-wiki.com/wiki/Safe_Cflags
http://manpages.ubuntu.co...n1/dpkg-buildflags.1.html

Thanks, ook even bekijken.

[Ertepeller]

Ploink schreef op zaterdag 17 maart 2012 @ 15:23:
De scheduler kun je ook achteraf nog wijzigen.
Linux Change The I/O Scheduler For A Hard Disk

Weet ik, het gaat ook om de default scheduler. Dan vergeet je het tenminste niet, wel handig als je voornamelijk met SSD's werkt. Anders doe ik het meestal via de bootparameters: elevator=deadline

Die pagina in je link is al een tikkie oud zie ik, de anticipatory scheduler bestaat niet meer namelijk

[Ertepeller]

MarcHeijerman schreef op zaterdag 17 maart 2012 @ 15:27:
[...]


Sorry even over heen gelezen, en wat doet dit precies, op deadline zetten ?
zoiets als:

na een i/o request die niet voltooid wordt, de request laten vervallen na een idle timer ?

Deadline heeft niet te maken met laten vervallen van een request, maar met de garantie dat een request binnen een bepaalde tijd wordt gehonoreerd.

Samengevat kan je zeggen: cfq is voor harde schijven, noop en deadline voor SSD's.

---

Hier staat wel een aardig overzicht (+ een boel meer).

Citaat v.w.b. de IO-schedulers:

Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.

1) Noop

Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Advantages:

Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.

Disadvantages:

Reduction in number of cpu cycles used is proportional to drop in performance.


2) Deadline

Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.

Advantages:

Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.

Disadvantages:

When system is overloaded, set of processes that may miss deadline is largely unpredictable.


3) CFQ

Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

Advantages:

Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.

Disadvantages:

Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.

[MarcHeijerman]

Ertepeller schreef op zaterdag 17 maart 2012 @ 16:10:
[...]


Deadline heeft niet te maken met laten vervallen van een request, maar met de garantie dat een request binnen een bepaalde tijd wordt gehonoreerd.

Samengevat kan je zeggen: cfq is voor harde schijven, noop en deadline voor SSD's.

---

Hier staat wel een aardig overzicht (+ een boel meer).

Citaat v.w.b. de IO-schedulers:
...............

Thanks voor deze uitleg !