Optimizing the Linux scheduler

One of the latest SySo (System software) courses inspired me to "optimize" the Linux scheduler. I ended up in modifying the very few parts of the Linux Kernel code that I understand. (And that's not a lot.) That means, the kernel now logs some poetic lines of consolation to the console if a panic occurs.

Unfortunately, it now refuses to compile, even without the planned modifications on the scheduler. :-> Note to self: Get that working! ;-)

Kids, don't try this at home! As noted before, I am a highly trained General Unit Engineered for Nullification, Thorough Harm and Efficient Repair. (It doesn't say I can't do the harm to myself! ;-))

Sidenote to the German-speaking readers: Natuerlich war es in der Tat nicht ganz ungefährlich, einfach in unbekanntem Kernelcode rumzuschreiben, ohne die dazugehoerige Dokumentation gelesen zu haben. Aber mit den Konsequenzen muss man halt leben, wenn man seinen Scheduler optimieren will. In einer Welt, in der man schon darauf hinarbeitet, sich von seinem Tuergriff entmuendigen zu lassen, muss man eben dann und wann Zeichen setzen, und Risiken eingehen, die der Türgriff nicht eingehen würde. Ich kann es mir nicht verkneifen, das mal zu zitieren:

"Dieser Türgriff würde wissen, wenn Sie zuhause sind. Er wäre so schlau, dass er den Hund rauslassen würde und wieder hinein, er würde aber eben nicht sechs andere Hunde ins Haus lassen. Er wuerde Fedex-Päckchen annehmen und signieren, wenn Sie nicht da sind."

Ich frage mich, ob sich der technische Aufwand eines elektronischen Türgriffs lohnt, wenn der dadurch gewonnene Komfort sich darauf beschränkt, dass man den Hund nicht mehr rein und raus lassen muss und der Türgriff meine elektronische Unterschrift an alle Postboten weiterreicht? Darüber hinaus darf man nicht das Szenario vergessen, dass der Türgriff abstürzt und keinen mehr rein laesst oder ein böswilliger Passant den Türgriff hackt und meinen privaten Schlüssel aus der Türgriff-Datenbank extrahiert.

Da bin ich ja mal gespannt... :-D