In a continuing discussion about the difference between pluggable security and pluggable schedulers, Linus Torvalds quoted himself:

"Another difference is that when it comes to schedulers, I feel like I actually can make an informed decision. Which means that I'm perfectly happy to just make that decision, and take the flak that I get for it. And I do (both decide, and get flak). That's my job."

He added, "which you seem to not have read or understood (neither did apparently anybody on slashdot)". Linus continued, "the arguments that 'servers' have a different profile than 'desktop' is pure and utter garbage, and is perpetuated by people who don't know what they are talking about." He then asked and answered his own question, "really: tell me what the difference is between 'desktop' and 'server' scheduling. There is absolutely *none*," going on to explain:

"Yes, there are differences in tuning, but those have nothing to do with the basic algorithm. They have to do with goals and trade-offs, and most of the time we should aim for those things to auto-tune (we do have the things in /proc/sys/kernel/, but I really hope very few people use them other than for testing or for some extreme benchmarking - at least I don't personally consider them meant primarily for 'production' use)."

"Completely fair scheduling is [a] really good thing, but if you want the best performance for certain applications you need to tune up some things," explained Michal Piotrowski in his announcement for the fifth version of his DeskOpt daemon. The daemon is a Python script that helps to automatically tune the I/O scheduler and the process scheduler to offer better performance for certain applications such as games or audio applications. The script supports the default CFS process scheduler and CFQ I/O scheduler, as well as the anticipatory I/O scheduler and the deadline I/O scheduler.

The small script utilizes an XML configuration file, deskopt.conf, used to define scheduler classes each supporting their own scheduler tunings. One or more applications can then be added to each scheduler class, and when any of the specified applications starts the daemon will automatically tune the schedulers per the settings in that scheduler class. As examples in the provided sample configuration file Michal defines a "games" scheduler class defining two games receiving the highest scheduler priority and an "audio" scheduler class receiving not quite as high of a scheduler priority.

Nadia Derbey posted a set of patches to the Linux Kernel Mailing List titled Automatic Kernel Tunables, or AKT, explaining, "this is a series of patches that introduces a feature that makes the kernel automatically change the tunables values as it sees resources running out." The kernel portion of the AKT framework is described as providing sysfs interfaces for registering tunables, and for activating the automatic tuning of registered tunables. Nadia explains the second feature, "it can be called during resource allocation to tune up, and during resource freeing to tune down the registered tunable." The userland portion of the framework provides an interface for configuring whether or not a tunable should be set automatically.

The default automatic adjustment routine provided by the patches simply allow a tunable to be configured with a minimum and maximum values, as well as a thresholds. If a monitored value grows beyond the defined threshold, the tunable is increased. If the monitored values shrinks below the defined threshold, the tunable is decreased. The patches also allow more complicated adjustment routines to be defined. The effort is part of the larger libtune project, aiming "at providing a standard API to unify the various ways Linux developers have to access kernel tunables, system information, resource consumptions."