Slashdot Mirror
Tuning The Kernel With A Genetic Algorithm
fsck! writes "Jake Moilanen provided a series of four patches against the 2.6.9 Linux kernel that introduce a simple genetic algorithm used for automatic tuning. The patches update the anticipatory IO scheduler and the zaphod CPU scheduler to both use the new in-kernel library, theoretically allowing them to automatically tune themselves for the best possible performance for any given workload. Jake says, 'using these patches, there are small gains (1-3%) in Unixbench & SpecJBB. I am hoping a scheduler guru will able to rework them to give higher gains.'"
A common criticism of Open Source is the accusation that it lacks innovation.
:-)
I mean, common. Just look at this. Amazing.
And even if it turns out to be not that good, it was still a good read
So how much additional complexity is added for a 1-3% perfomance improvement? I'm all for more speed, but keeping thinks simple can often be more improtant when it comes to maintainablity and adding additional features.
And the knowledge that they fear is a weapon to be used against them...
If a parameter space is complex enough that you can use a genetic algorithm to tune it, the solutions it finds may have all sorts of unexpected potholes, bugs, etc.
In other words, non-competitive genetic algorithms are only as smart as the fitness function you give them. If your fitness criteria aren't smart enough to cover all the bases, your solutions will have unpredictable deficiencies.
1-2% gain is in the borders of statistical error. Definitely not worth the increased complexity of the solution.
Nice troll, but your sarcasm presents a common fallacy: that work on one issue (adding features like this) means that less work is being done on some other issue (cleaning up security problems). The fact is, throwing more people at a problem does not always make it better, especially if the people you throw at it don't know the subject (which the author of this algorithm may not, can't speak for him).
In other words: if you have someone who's good at writing Genetic Algorithms, but not so good at searching for kernel vulns, why devote that person to security? Why not let them write their contribution, and have the guys who are good at security do their part separately? Why should we only do one thing at once?
The main problem with this or any other adaptive tuning mechanism is actually acquiring performance metrics.
What is the system using to decide if a new parameter set is better than a previous? What is the fitness test?
Some applications are disk-bound, others are CPU-bound, others are network bound. The performance dance is often non-obvious (e.g. some applications will achieve generally higher performance by allowing I/O higher priority than context switching, while others that appear to perform in a similar manner will achive higher performance by reversing that order).
The kernel does not have any mechanism to determine if a particular application is performing better or worse, it can only really get a guage of throughput and load. While this MAY be enough to get small systemwide performance gains, in order to really acheive significant application-specific performance gains, I think that applications would need to explicitly add support for adaptive tuning by logging relevant performance metrics for the kernel to tune around.
Thoughts?
The reason that it can be true that 1+1 > 2 is that very peculiar nonzero value of the + operator
In reality, the basic GA framework is "just" another efficient search algorithm, no cooler or more complex than, say, a hash table or a binary search tree; at its simplest, a GA is a way to find an optimal configuration of components without looking at all possible (potentially explosively exponential) combinations; instead, you look at just some permutations, and as you iterate through generations, applying breeding and mutation, you arrive at a generation which is statistically close to optimal.
GAs are also in no way new or unproven technology; a nice example of mainstream use is PostgreSQL's query planner, which uses GAs to optimize query plans.
They might converge on a point of attraction that is not the highest possible.
Mutation helps with convergence issues.
Sure the only way is to exhaustively search the "chromosome" space for every possibile combination, and computers are good at brute force!
Um, I don't even know how many parameters are involved to be adjusted, but it does not take that many to make exhaustive search useless, even for a computer.
The sharp edge of a razor is difficult to cross. Thus the wise say the path to salvation is hard...
First thing: A GA is only truly effective if you let it exhaustively search the search space
If you have the resources to exhastively search the space... you don't need a GA.
A GA is generally used when the search space is hopelessly huge and you need to chart a course from A to(wards) B but you don't know the way.
And in finding this solution, which is "grown", not engineered, it's much easier for unintended wierdnesses to creep in. A GA might solve problem X by ruining performance on problem Y, something that you, as a software engineer, would never even consider viable, and hence you forgot to force the fitness function to check problem Y along with problem X.
Writing a GA is simple. Writing a GA that delivers results, now that is a different beast alltogether. My experience has shown me that there are some rather more complicated things that need to be taken into account such as:
The reason that it can be true that 1+1 > 2 is that very peculiar nonzero value of the + operator