Een filesysteem mounten met de opties noatime en nodiratime kan een merkbare reductie in disk transacties lijden en zeker op het root-filesysteem kan hier systeembreed een verbetering komen. Maar in de huidige tijden waar zoekmachines voor op de desktop populair worden is dit ook een punt van aandacht. Zeker als je bedenkt dat voor het scannen van alle directories ook bijna alle metadata moet worden bijgewerkt.

Helaas werkt noatime niet goed voor alle applicaties zoals bijvoorbeeld Mutt welke vertrouwt dat de atime van een bestand de werkelijkheid weergeeft. Om deze reden kan een filesysteem ook met de optie relatime worden gemount waardoor de atime alleen wordt bijgewerkt als het bestand ook wordt aangepast om zo bepaalde applicaties te laten werken. En hoewel dit misschien tegen Posix ingaat maken deze maatregelen een machine wel stiller en wat sneller.

Gelukkig zit er in sommige systemen nog wel wat ruimte om zonder aanpassingen aan de hardware er wat meer performance uit te krijgen. Bij veel Linux-distributies heb je de mogelijkheid om virtuele consoles te gebruiken, maar bijna niemand gebruikt deze virtuele consoles nog terwijl ze wel draaien. Dit terwijl je gelijktijdig bijvoorbeeld KDE of GNOME gebruikt en het is misschien een paar een megabyte, maar het is wel voldoende om /var/run in geheugen te houden.

In het bestand /etc/inittab kom je het volgende tegen:

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

En door dit te veranderen naar:

1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

Als men nu een `kill -HUP 1` doet of reboot dan zal er nog maar een console overblijven welke kan worden gebruikt in geval van problemen. Maar de overige virtuele consoles zijn gestopt en nemen nu niet meer een paar honderd kilobyte per console in beslag. En dit is iets wat soms net het kleine beetje kan zijn om wat oudere of kleinere machines snel te houden.

Als eerste stap is het laden van de module welke de processor kan aansturen om de snelheid aan te passen. In mijn geval is dat p4-clockmod omdat ik nog een oudere Pentium 4 processor heb, maar als je zoekt in de directory /lib naar de directory cpufreq dan kon je andere modules ook tegen. De andere module is cpufreq_ondemand en waarom wordt later duidelijk.

Plaats deze modules in /etc/modules:

p4-clockmod
cpufreq_ondemand

Nu moet nog worden duidelijk gemaakt welke policy er gebruikt moet worden als de machine opstart. En hoewel dit per processor-core is in te stellen heb ik dit alleen gedaan voor cpu0, omdat cpu1 een hyperthread is en daarmee afhankelijk is van cpu0. Het is dus belangrijk om dit voor elke fysieke processor-core in te stellen. Een tweede wat ik heb ingesteld is een ondergrens, want mijn huidige processor doet er te lang over om de snelheid te verhogen. Dit is een probleem in de Pentium 4 processoren en lijkt 1200 MHz een goede snelheid als ondergrens, maar moderne processoren zouden hier geen last van moeten hebben.

Plaats de regels in /etc/sysfs.conf:

devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu0/cpufreq/scaling_min_freq = 1200000

Nu is het enige wat nog nodig is is een reboot om alles te activeren of je met de aanpassingen met de hand activeren, maar een reboot is vaak makkelijker. Je zal in /proc/cpuinfo nu de actuele snelheid van je processor zien. En als je hier vanaf wilt dan zet overal een hash-teken voor en reboot.

Maar waarom geen daemon en alleen de policy ondemand? Er wordt gesteld dat de snelheid moet worden beperkt vanwege hitte productie, maar dit is iets wat de kernel moet oplossen en ook daadwerkelijk doet gelukkig. Zeker als je bedenkt dat een kernel altijd alle triggers heeft om dit te bewerkstelligen, maar ook de juiste prioriteiten heeft om dit uit te voeren waneer het nodig is. Een proces in userland kan bijvoorbeeld niet de juiste prioriteit krijgen of toevallig naar disk zijn verplaatst omdat het geheugen nodig was.

Een andere stelling is dat een lagere snelheid altijd bespaart, maar is dat wel zo? De mensen van lesswatts.org hebben er een mooi voorbeeld over wat misschien nog wel wat wenkbrauwen zal doen fronzen. Daarbij wil je je performance beperking en zeker nu de tickless kernel zijn intrede heeft gedaan om de processor zoveel mogelijk in idle-stand te brengen om daadwerkelijk energie te besparen.

Zulke verhoging zijn natuurlijk altijd leuk om te horen, maar of ze bruikbaar zijn. Want voor veel klanten is de huidige snelheid al zeer acceptabel of je moet een ferfent usenet downloaders zijn. Gelukkig zijn veel mensen dat niet of heel beperkt en zo ook ondergetekende. En voor een eenmalig bedrag van 25 euro betaal ik nu wel elke maand 10 euro minder voor dezelfde snelheid als voorheen. Nu klinkt dat niet veel, maar het is wel 120 euro per jaar.

In de afgelopen tijd heb ik meer van dit soort vaste lasten onder de loep genomen met goed succes. Zeker omdat dit soort kosten erin sluipen en onopgemerkt blijven totdat je ze eens op een rijtje zet. Want mobiele telefonie was hiervoor ook al leuke besparing terwijl ik niks heb hoeven in te leveren. Het is nu dan ook alleen nog wachten totdat de Fritz!box 7270 uitkomt en XS4ALL nu eindelijk eens 085-nummers gaat leveren ipv 087-nummers. Maar naar verwachting komen ze beide in het derde kwartaal van 2008.