Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?
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."
GA's tend to use a lot of CPU to evaluate the current population, and to rank them appropriately. In order to test different individuals in the population, it must actually try them out and measure how well it actually did. During this early discovery phase, that means it's going to choose many bad scheduling plans prior to discovering one that works better.
One of the hardest things to do is write a good fitness test. How would the kernel measure the scheduler's fitness? Avg latency? Throughput? Shouldn't the user have some say on the types of variables that are measured, what s/he finds important? (IF the test is moved into user space, then the test could be customized, but it seems like it'd be expensive.)
Except for machines that have pretty regular use-patterns, (like dedicated machines for single tasks) and the GA's current optimal solution will remain valid for a long time, I could see more effort spent in search of optimizing than is saved. Especially if the optimal solution continues to change, as the machine's usage changes.
If it can quickly converge on a good solution, then this might not be a problem. For machines requiring low latency and fairly deterministic behavior, this could also be bad as the various scheduling plans could cause it to behave erratically for small periods of time.
The dilemma is that I wouldn't use such a task on a production box where timing is important (which is the type of work I generally do), and would only use such a scheduler for a desktop machine, where erratic behavior has minimal consequence. However, the desktop machine is one where usage changes occur frequently, and so no solution will remain valid for long. (Thus the GA will spend a lot of time optimizing and always playing catch-up.)
But still, it sounds fascinating, and if it completes very quickly and doesn't negatively affect performance in real-world situations, it might be worth taking a look (after a lot of testing.)
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
One of the hardest things to do is write a good fitness test. How would the kernel measure the scheduler's fitness? Avg latency? Throughput? Shouldn't the user have some say on the types of variables that are measured, what s/he finds important? (IF the test is moved into user space, then the test could be customized, but it seems like it'd be expensive.)
Except for machines that have pretty regular use-patterns, (like dedicated machines for single tasks) and the GA's current optimal solution will remain valid for a long time, I could see more effort spent in search of optimizing than is saved. Especially if the optimal solution continues to change, as the machine's usage changes.
If it can quickly converge on a good solution, then this might not be a problem. For machines requiring low latency and fairly deterministic behavior, this could also be bad as the various scheduling plans could cause it to behave erratically for small periods of time.
The dilemma is that I wouldn't use such a task on a production box where timing is important (which is the type of work I generally do), and would only use such a scheduler for a desktop machine, where erratic behavior has minimal consequence. However, the desktop machine is one where usage changes occur frequently, and so no solution will remain valid for long. (Thus the GA will spend a lot of time optimizing and always playing catch-up.)
But still, it sounds fascinating, and if it completes very quickly and doesn't negatively affect performance in real-world situations, it might be worth taking a look (after a lot of testing.)
-- Chris