login
Header Space

 
 

Linux: Tuning The Kernel With A Genetic Algorithm

January 7, 2005 - 9:59am
Submitted by Jeremy on January 7, 2005 - 9:59am.
Linux news

Jake Moilanen provided a series of four patches against the 2.6.9 Linux kernel [story] that introduce a simple genetic algorithm used for automatic tuning. The patches update the anticipatory IO scheduler [story] and the zaphod CPU scheduler [story] 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."

Genetic algorithms as used in machine learning are modeled after the process of evolution as observed in nature, and are a field within the science of artificial intelligence. The idea is to generate a "population" defined with unique strings of "chromosomes", to test each of these chromosome strings for "fitness", to select a subset of the chromosome strings with the best fitness and use them to create new chromosomes, to apply random mutation to a small subset, and finally to start the process all over again. Over time, all the chromosomes should "evolve" toward having the best possible fitness, as defined by the algorithm.

In Jake's patch, the chromosome strings are possible tunings for Linux kernel internals, and fitness is measured in overall performance. Essentially, a large pool of possible tunings are selected (referred to above as chromosome strings). Each of these possible tunings is tested under the current workload, measured for best performance (referred to above as fitness). All of the tunings are then ordered from best performance to worst, and the worst half of the performers are replaced with new possible tunings derived from the best half of the performers. Finally, random mutation is applied to slightly modify some of the tunings. Jake explains, "over time the tunables should converge toward the optimal settings for that workload. If the workload changes, the tunables should converge to the new optimal settings (this is part of the reason for mutation)."


From: Jake Moilanen [email blocked]
To:  linux-kernel
Subject: [ANNOUNCE 0/4][RFC] Genetic Algorithm Library
Date: 	Thu, 6 Jan 2005 10:08:44 -0600

I'm pleased to announce a new in-kernel library to do kernel tuning
using a genetic algorithm.  

This library provides hooks for kernel components to take advantage of a
genetic algorithm.  There are patches to hook the different schedulers
included.

The basic flow of the genetic algorithm is as follows:

1.) Start w/ a broad list of initial tunable values (each set of
	tunables is called a child) 
2.) Let each child run for a timeslice. 
3.) Once the timeslice is up, calculate the fitness of the child (how
well performed).
4.) Run the next child in the list.
5.) Once all the children have run, compare the fitnesses of each child
	and throw away the bottom-half performers. 
6.) Create new children to take the place of the bottom-half performers
	using the tunables from the top-half performers.
7.) Mutate a set number of children to keep variance.
8.) Goto step 2.

Over time the tunables should converge toward the optimal settings for
that workload.  If the workload changes, the tunables should converge to
the new optimal settings (this is part of the reason for mutation). 
This algorithm is used extensively in AI.

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.

The main area that could use reworking is the fitness calculation.  The
problem is that the kernel is looking more at the micro of what's going
on, instead of the macro.  I am thinking of moving the fitness
calculation to outside the kernel.

However, I would advocate keeping the number of layers needed to communicate
between the genetic library and the hooked component down in order to
keep it as lightweight as possible.

The patches are based on 2.6.9 and still a little rough, but here is the
descriptions:

[1/4 genetic-lib]: This is the base patch for the genetic algorithm. 
	It's based against 2.6.9.

[2/4 genetic-io-sched]: The base patch for the IO schedulers to use the
	genetic library.

[3/4 genetic-as-sched]: A genetic-lib hooked anticipatory IO scheduler.

[4/4 genetic-zaphod-cpu-sched]: A hooked zaphod CPU scheduler.  Depends
	on the zaphod-v6 patch.

Please send comments,
Jake Moilanen


From: Jake Moilanen [email blocked] Subject: [ANNOUNCE 1/4][RFC] Genetic Algorithm Library Date: Thu, 6 Jan 2005 10:14:47 -0600 Here is the base patch for the genetic-library. It includes generic routines for modifying and manipulating genes of children. If a specific routine is needed, that can be used instead. Signed-off-by: Jake Moilanen [email blocked] --- [patch]
From: Jake Moilanen [email blocked] Subject: [ANNOUNCE 2/4][RFC] Genetic Algorithm Library Date: Thu, 6 Jan 2005 10:18:38 -0600 This is the base patch for the io-schedulers. It contains the fitness routine, disk_calc_fitness(), that could use a rework. Signed-off-by: Jake Moilanen [email blocked] --- [patch]
From: Jake Moilanen [email blocked] Subject: [ANNOUNCE 3/4][RFC] Genetic Algorithm Library Date: Thu, 6 Jan 2005 10:22:49 -0600 This is the hooked anticipatory IO scheduler. Here is an example of the hooked scheduler. It should optimally tweak the tunables for the current workload. If nothing else, hopefully the genetic-lib will help scheduler writers find the optimal tunable settings. Signed-off-by: Jake Moilanen [email blocked] --- [patch]
From: Jake Moilanen [email blocked] Subject: [ANNOUNCE 4/4][RFC] Genetic Algorithm Library Date: Thu, 6 Jan 2005 10:27:42 -0600 The hooked zaphod CPU scheduler patch. It depends on the zaphod-v6 patch. The ranges for the tunables could be tweaked better. Signed-off-by: Jake Moilanen [email blocked] --- [patch]



Related Links:

AttachmentSize
genetic-lib.patch18.17 KB
genetic-io-sched.patch4.11 KB
genetic-as-sched.patch6.25 KB
genetic-zaphod-cpu-sched.patch10.57 KB

This is really the time or th

January 7, 2005 - 10:52am
Anonymous (not verified)

This is really the time or the place, but I for one, well come our new self-tuning mutating genetic algorithm optimised kernel overlords.

For some reason, it lacks a certain ring.

Whoa

January 7, 2005 - 10:53am

Whoa, at the first look all this sounds more like Sci-Fi, but I have to admit it's pretty interesting idea :)

It isn't as cool as it looks

January 7, 2005 - 11:14am

It isn't as cool as it looks like, it's rather simple too. Problem is that making good selections is hard, as it depends on a lot of external and long term things, and the situation may change often and quick. Though if they could get 5% or more improvement in something else than microbenchmarks then that would be a good achievement.

A little smarter with known workloads?

January 7, 2005 - 11:56am
Jel (not verified)

This could be pretty cool. Only thing is... I'm worried about what happens on work breaks, where I might want to fire up a totally different set of apps. Would it start analysing the new workload on each change?

Instead, could this be made to recognise workloads it has already optimised, and to simply change profile for those?

Good stuff, either way. Can't wait to see it in my mainstream kernel :)

That's why mutation is in there

January 8, 2005 - 1:03pm
Anthony (not verified)

Mutation makes sure the scheduler constantly tries out variations of the best settings to discover these changes, so, yes, when the load on the machine changes, and the scheduler might perform better under different settings, the GA will figure this out as it's constantly trying out new variations.

I think the GA can even be tuned to better adapt to such changes as compared to the current implementation by increasing the mutation rate for a short period of time when a decrease in average fitness is discovered. The interested reader might want to look to Juergen branke's book on genetic algorithms in dynamic fitness environments for some optimization of the current implementation. Personally (I'm an academic doing related work) I would implement the genetic algorithm as a diploid algorithm but this is beyond the scope of this thread and would probably not give a very noticeable gain, except when work loads and schedule settings need to change very rapidly.

Oops forgot tomention coolest about diploidy

January 8, 2005 - 1:06pm
Anthony (not verified)

A diploid genetic algorithm can remember previous solutions for workloads it did encounter previously, so adding diploidy to the GA might help out with your problem of workloads that come back from time to time, the diploid GA would easily pick those out of its memory an return to the optimal settings for this workload fairly rapidly.

Suggestion for changing workloads

January 8, 2005 - 2:39pm
Anonymous (not verified)

Not an expert by any means, but I have a suggestion for workloads that change regularly such as desktop usage.

If the algorithm notices a sudden drop in performance, the mutation rate jumps up for a few iterations. This should allow for a quicker adjustment to the new workload.

That's exactly what I propose

January 10, 2005 - 9:34am
Anthony (not verified)

That's exactly what I proposed, not?

Well don't I feel stupid. N

January 11, 2005 - 1:43pm
Anonymous (not verified)

Well don't I feel stupid. No idea how that one slipped past me. Ummm - good idea. Kudos :)

Sounds great...

January 7, 2005 - 12:00pm
My Name Was Taken! (not verified)

Wow, this sounds great. I imagine it's more suited to a box which sits there doing a known set of work tasks, and doesn't get changed to other tasks very often...

Mmmm, might be very nice for game servers! :)

indeed, I dont think its very

January 7, 2005 - 2:03pm
superstoned (not verified)

indeed, I dont think its very usable for desktop systems, the workload always changes, and the genetic algoritm is always adjusting...

i don't see it's use..

January 7, 2005 - 4:07pm
Rinoplastica (not verified)

i don't see it's use..

Broken concept

January 7, 2005 - 11:13pm
Anonymous (not verified)

"the genetic algoritm is always adjusting..."

No, it's not. The settings of the schedulers are always adjusting, the genetic algorithm stays the same. But this slip of your mind shows indeed the inherent problem with using a genetic algorithm for scheduling: the decisions a scheduler has to make are the same as those of the genetic algorithm! Postponing those decisions to another layer will not help you, the problem stays the same, and has to be solved once. Hence a sheduler needs to be static. Or an infinite amount of schedulers, selection mechanisms and genetic algorithms all tuning eachother to determine the optimal workload are required.

That said, a genetic algorithm for the kernel is a wonderful addition for finding optimal default values and perhaps for tuning algorithms. And it shows what crazy things can be done with/to Linux.

Layering can help

January 8, 2005 - 11:49am
Mark Williamson (not verified)

I think it's promising - a library that's available for general use in the kernel for tuning settings using a GA. It avoids each subsystem having to "roll their own" optimiser.

You take for granted that an

January 8, 2005 - 1:11pm
Anonymous (not verified)

You take for granted that an optimal genetic algorithm can be developed which is useable for all subsystems of the kernel. I argue that even a genetic algorithm solely used for optimizing the schedulers is as hard to make as those schedulers. The Linux schedulers are good currently, and scalable. A genetic algorithm is no magic solutions to all your problems, only to magic numbers like default settings. Thus no runtime advantage for the kernel.

You take for granted that a

January 8, 2005 - 1:55pm
Mark Williamson (not verified)

You take for granted that an optimal genetic algorithm can be developed which is useable for all subsystems of the kernel.

The GA library itself is just a helper to kernel subsystems that wish to use a GA. The functions for combining genes, mutating genes, calculating the fitness of a set of genes, etc are defined by the subsystem in question (e.g. the CPU scheduler) and passed to the library in a struct genetic_ops.

In principle, only the generic parts of the algorithm reside in this library. Each scheduler (or whatever) then defines these functions according to its specific needs. The GA lib just provides a uniform framework and "cranks the handle" for the natural selection process.

A genetic algorithm is no magic solutions to all your problems, only to magic numbers like default settings.

OK, it's definitely worth pointing out that GAs are not magic solutions (or necessarily worthwhile at all). I'm with you on that one.

It still seems to me that GAs for runtime settings are worth considering, although arguably in some (maybe even all!) cases, you might get better gains by different techniques.

For the kind of applications posted by Jake, it seems to me the GA itself might be better off in userspace - it doesn't really *need* to be in the kernel.

I have no specific objection

January 8, 2005 - 4:42pm
Anonymous (not verified)

I have no specific objection to this GA framework, but I object to the idea of using genetic algorithms for things like schedulers and especially to the idea that they are some panacea to all algorithmic problems. If one has a problem for which one can't conjure a good algorithm, and is on the brink of throwing ones arms up in despair, then a GA is an excellent idea.

I for one can appreciate how

January 8, 2005 - 5:34pm
Timothy (not verified)

I for one can appreciate how an optimal solution can be reached using genetic algorithms where the actual optimum varies or where calculation is difficult.

I once wrote a progam using GAs to calculate a linear regression line ("line of best fit"), the formula for which I didn't know at that time. In this case there was an available formula, but that isn't always the case. In this case, no "perfect" formula exists since the optimum depends on what you have running.

Unfortunately GAs are quite processor intensive. I'm impressed that Mr Moilanen managed to get performance gains on his first release. Since standard versions of the scheduler were quite probably tuned against similar benchmarks to those used, a 1-3% gain even after the loss required to implementing the GAs is quite impressive. For more unusual tasks I would expect even better gains. Hopefully later, more efficient versions will increase performance gains further. Congratulations.

The GA doesn't run all the time

January 9, 2005 - 12:55pm
Anonymous (not verified)

You just run until you find a good set of parameters and then
configure those and disable GA.

Basically it's an attempt to automate the act of a human tuning
parameters for a workload.

The main problem is that the act of tuning parameters shifts to
the act of tuning the fitness function.

That might be a good idea if

January 10, 2005 - 9:41am
Anthony (not verified)

That might be a good idea if your workload doesn't change over time. But I would still opt for a constantly optimizing the parameters since you never know what'll happen in the long run with your system, and which unpredictable events may happen that break your "optimal" settings. A GA is known to create good solutions for problems it faces, but these optimal settings can be easily broken for some change in the environment. Natural selection figures out how to "hack" the settings to figure out the optimal performance, but i wouldn't trust these performances in the long run in the dynamic environment your system resides in, as it'll turn out to be a horrible choice of parameters for the slightest change in workload.

"If one has a problem for whi

January 8, 2005 - 5:43pm
Anonymous (not verified)

"If one has a problem for which one can't conjure a good algorithm, and is on the brink of throwing ones arms up in despair, then a GA is an excellent idea."

That pretty well describes scheduling, especially for pathological workloads.

I'd use whatever worked best

January 8, 2005 - 7:23pm
Mark Williamson (not verified)

I'd use whatever worked best ;-) Any algorithm is going to have internal tuning knobs of some sort, be they internal counter variables or whatever. From a user / admin PoV, I wouldn't mind whether they were tweaked by the scheduler or by a GA library as long as it works well.

You have a good point that GA schedulers are not deterministic. For general purpose use, I doubt that'll worry people as long as the performance is good. The increasing interest in stricter realtime guarantees might provide conflict here, however.

I think a genetic algorithm i

January 10, 2005 - 10:47am
martinus (not verified)

I think a genetic algorithm is a good idea for schedulers, because it is adaptive. You can hard code a good scheduler if you know exactly for what tasks a machine will be used later, but IMHO a dynamic solution is much better. Of course it does not have to a GA (but it has the advantage of sounding uber-cool, just like neural nets ;-) I am shure there are other optimization algorithms that are better fitted to this problem.

Another broken concept

January 8, 2005 - 2:23pm
Jaka Močnik (not verified)

Well, your post just shows that your understanding of using a GA for optimization of anything (not just scheduler behaviour) is rather flawed: if you had an exact or a good aproximative algorithm, which would not be very time consuming, for tuning the scheduler behaviour, then you would use that one. Lacking such an algorithm, you might very well try GA or simulated annealing or something similar. No one is searching for the Perfect Scheduler for All Workloads(tm) here - it can probably be shown that no such thing exists. A static scheduler with settings A might work well for some workload sets, a static one with settings B might work well for some other sets and a dynamically tuned one might work better for some others and there is no reason not to try GA for the latter approach.

If the task of optimizing/dev

January 8, 2005 - 4:18pm
Anonymous (not verified)

If the task of optimizing/developing a certain algorithm is of equal complexity and difficulty as developing the selection mechanism of a GA, then I do hope I am allowed to say that a GA won't buy you anything. A GA is usefull for developing algorithms which are far more complex than the GA itself.

Your reasoning is sound, but you assume that the behaviour of the scheduler has to be tuned. I'm arguing that it should be static. I guess my definition of scheduler behaviour differs from yours. Of course a scheduler will react differently to different workloads, but if a specific situation reoccurs, the scheduler should react consistently. That is what I mean with a static scheduler behaviour. The whole purpose of a scheduler is to anticipate change in the workload and that is why changing the scheduler to adept to the current workload is a flawed idea. Using a GA as a scheduler is a different matter, and my first point is my answer to that.

Perfect Scheduler for All Workloads(tm)

January 8, 2005 - 4:52pm
jldugger (not verified)

Actually, its been proven that in the worst case scenario, you can't finish more than 25 percent of the real time tasks given to you. It involves a ridiculusly ordered series of events, where you have ever increaingly long requests paired with a series of short requests. Essentially its a workload of 150 percent of capacity. They've also shown that you can't do much better than 75 percent under a lot less strained system (maybe 103 percent). How this transiitons to the world of "ASAP please" UNIX computing, I'm not exactly sure. I'm nearly certain though that you could disprove the Perfect Scheduler. Especially given that the best you can do requires perfect knowledge of the future.

So is that how this gray box

January 7, 2005 - 12:33pm
Anon (not verified)

So is that how this gray box of magic and electricity puts e-mail on my screen?

what is this slashdot?

January 7, 2005 - 12:51pm
Anonymous (not verified)

what is this slashdot?

Never heard of something cooler.

January 7, 2005 - 8:20pm
Enrico (not verified)

This patch lefts no room for improvement.. converging to the optimum settings is something unreachable for every preprogrammed scheduler. Compliments to the author.. that's a STEP in SCIENCE.
You rock.

You forgot to contemplate sch

January 7, 2005 - 11:27pm
Anonymous (not verified)

You forgot to contemplate schedulers without any knobs in your euphoria. And as i said in a previous comment: using a genetic algorithm for tweaking schedulers is conceptually flawed, because the nature of the problem they both need to solve is exactly the same. Only in chosing the best static settings a genetic algorithm will safe you.
You scissors.
I win. ;-P

There _are_ knobs

January 8, 2005 - 11:53am
Mark Williamson (not verified)

The advantage in principle of the GA is that it can evolve new good *scheduler internal* settings each time the workload changes and then stick with them.

There are still knobs to tweak the behaviour of the scheduler. From userspace, the sysadmin and users can nice / renice just like they usually would.

It is the task of the schedul

January 8, 2005 - 12:57pm
Anonymous (not verified)

It is the task of the scheduler to react to workload changes, and moving the algorithm from the scheduler to the genetic algorithm buys you absolutely nothing. Throughput, latency and fairness maximation for any workload is the goal, and whether the selection mechanism in the genetic algorithm solves that by tuning the settings of a dumb scheduler or the scheduler fulfills its purpose only moves the place where the decisions have to be made. The fundamental problem stays the same, and therefore a genetic algorithm can only be usefull to determine optimal default settings for a given goal for a specific system.

Nice levels are no knobs for the behaviour of the scheduler, but for the behaviour of individual processes.

I'm sorry for being a pessimist/realist among these cheering optimists...

You seemed to be implying tha

January 8, 2005 - 1:41pm
Mark Williamson (not verified)

You seemed to be implying that the GA removed some control knobs from the scheduler. What knobs does the GA remove?

Nice levels are no knobs for the behaviour of the scheduler, but for the behaviour of individual processes.

They do control the behaviour of the scheduler by affecting when it schedules the processes concerned. Nice values are used in deciding wehat to schedule next.

They're the only userspace-visible "knobs" I can think of, unless there's something in /proc that I'm not aware of.

It is the task of the scheduler to react to workload changes, and moving the algorithm from the scheduler to the genetic algorithm buys you absolutely nothing.

OK, I agree that (assuming the GA buys you anything) you could get the same benefits by changing the scheduling algorithm. But if the GA is also applicable elsewhere then it may be worth splitting it out, as this patch does.

I'm sorry for being a pessimist/realist among these cheering optimists...

Not at all, it's worthwhile to keep everyone's feet on the floor, especially when a trendy thing like GA is involved :-)

No, I wasn't implying that. A

January 8, 2005 - 4:32pm
Anonymous (not verified)

No, I wasn't implying that. And "knobs" are *internal settings* of the scheduler, and not something userspace-visible per se. Some schedulers have a knob for tuning between throughput and latency for example. The staircase scheduler of Con Kolivas is an attempt to have a scheduler without any magic knobs.

I consider nice values to be part of the workload, or context in which a scheduler has to make a decision if you wish. A GA continually fiddling with internal scheduler knobs for tuning its behaviour/policy just makes the scheduler a puppet on strings.

"A GA continually fiddling wi

January 8, 2005 - 6:01pm
Anonymous (not verified)

"A GA continually fiddling with internal scheduler knobs for tuning its behaviour/policy just makes the scheduler a puppet on strings."

Exactly. If you want near-optimal performance, particularly under oddball workloads, the tuning algorithm must necessarily not be hard-coded to a narrow range of possibilities. GAs dynamically optimize, can get away with fewer hard-coded assumptions, and can escape from some pathological behaviors.

I don't think the original po

January 8, 2005 - 7:14pm
Mark Williamson (not verified)

I don't think the original poster was suggesting anything that would make the scheduler less flexible, just that a GA isn't the correct way to achieve that flexibility.

See my comments in the above

January 8, 2005 - 7:32pm
Anonymous (not verified)

See my comments in the above thread. I believe you can figure out who I am, as I have basically the same message everytime. I don't reason in detail why it is so, as that is left as an exercise to the reader. I lay my fingers at rest after this post, and will not stress them furthermore.

There is one thing we agree on and that is that schedulers shouldn't have magic settings. If you think a GA will remove those, then keep in mind that the genetic algorithm, particularly the selection mechanism, will have to be designed without any such tunable settings.

Left as an exercise...

January 10, 2005 - 7:26am
F.A. (not verified)

Correct me if I'm wrong, you're arguing that the GA is just shifting the problem from the scheduler to the GA itself, that is a decision needs to be taken, be it in the scheduler or in the GA, so wherever you make it is of no relevance, as long as you make it.

Is that right?

If so, then what I have to tell you is that there's no magic static algorithm that can fit every possible workload scenario, hence either you have n different algorithms for the n possible scenarios, and a means to determine each and every time which scenario is the one currently presenting itself, or you have one and only algorithm that can adapt itself to the current scenario the best possible way.

The GA tends to the optimal solution by definition, a static algorithm only gives optimal performances for the best possible case such an algorithm was designed for.

A GA continually fiddling w

January 8, 2005 - 7:12pm
Mark Williamson (not verified)

A GA continually fiddling with internal scheduler knobs for tuning its behaviour/policy just makes the scheduler a puppet on strings.

OK, that's fair but you could look at it another way: instead of a scheduling algorithm relying on external control, you could say the result is a new scheduling algorithm, similar to the original but with GA features.

So it comes back to a choice between scheduler algorithms, which will depend on what the benchmarks say for example use cases.

Let me quote myself, from my

January 8, 2005 - 8:17pm
Anonymous (not verified)

Let me quote myself, from my first comment:

"the decisions a scheduler has to make are the same as those of the genetic algorithm! Postponing those decisions to another layer will not help you, the problem stays the same, and has to be solved once."

GA and more broadly evolution are exceptionally powerfull mechanisms. They make such complicated and wonderfull things as life possible, and potentially even a stable universe. But in runtime a genetic algorithm does not help scheduling.

Some off-topic musing: I don't mind people disagreeing with me, but it would be convenient if they would attack my assumtions or reasoning in such a case. ;-)
Unfortunately I'm doomed to be misunderstood, either by people's refusal to carefully read what I say or by my gross incompetence to express myself clearly. It doesn't help that in general critique is anathema or merely perceived as something negative.

No, I'm not implying anything bad about my critics in this discussion. Just that in the context of my posts, replies were sometimes off the mark in my view. But then, let us struggle for the steer of a discussion, and may the strongest, the most persistent or the wickest turn it in his direction! :-)

Non-sensical

January 8, 2005 - 8:56pm
Anonymous (not verified)

Given that there was a measured (small) benefit according to the test performed, I fail to see how you can assert a GA at runtime does not help scheduling -- when in fact, it did.

I do question your reasoning on this matter. You have not really *explained* why using a GA as a part of the scheduling algorithm is a unhelpful thing. You assert that the GA and scheduler are doing the same thing, but that, to me, shows a lack of understanding.

The GA is just one particular component of this improved scheduler. Obviously, it could theoretically be replaced by some (unknown) determistic algorithm that would always choose the optimum solution. However, it may be that it's easier to use a relatively opaque optimization algorithm like GA until something better comes along.

To categorically state that "runtime a GA does not help scheduling" feels like an appeal to your own perceived authority to me, rather than anything resembling reasoning...

he does not argue that a ga a

January 10, 2005 - 8:24am

he does not argue that a ga as part of the scheduling algorithm is an unhelpful thing. he merely argues that using a ga to twiddle the knobs of the scheduler to perfection gains nothing over statically setting those knobs to the same settings the ga determines to be perfect. i.e. the ga adds nothing but its overhead.

as someone else posted: using a ga to determine the aforementioned optimal settings is fine. but that should be done once, or, at the very least, not constantly.

the whole thing does suggest that the scheduler is inherently imperfect if twiddling its knobs is so complex that we resort to a ga to find the best settings.

Me quoting you quoting yourse

January 8, 2005 - 9:47pm
Mark Williamson (not verified)

Me quoting you quoting yourself ;-)

"the decisions a scheduler has to make are the same as those of the genetic algorithm! Postponing those decisions to another layer will not help you, the problem stays the same, and has to be solved once."

Yes, I definitely see your point here - and I understand it better than when we started this discussion ;-) The GA scheduler doesn't give us anything we couldn't get anyway.

I don't have a problem with using the GA in a scheduler if that's the best solution on offer but I agree it's not clear it is. I'll still be interested to see the progress of this patch - it does look useful & promising, particularly since it is potentially useful to other kernel subsystems.

It's been good (and useful) to discuss this with you!

Have I got this right?

January 10, 2005 - 6:19am
Anonymous (not verified)

Ok, I've followed the thread and think I've got it clear, hopefully:

Presumption -
There is a Scheduling Algorithm (SA) that can dynamically adapt to a given workload to provide a near optimal solution.

Assuming this algorithm can be coded then there is no need for the use of run-time GA. (The algorithm is flexible by itself to adapt to the situations it perceives).

In fact the use of run-time GA shows that the current algorithm is missing a layer of complexity to dynamically adapt to the workload. This flexibility is actually being done by the GA layer. (This is where we are currently gaining by having the GA do the work).

If the complexity of the dynamic reaction is greater than that of the GA then doing the GA may be an overall win. Although I'm sure it's not beyond the brighter individuals here to work out what variables the GA changes and when and to add another algorithm that sits above the current SA that does exaclty that but does not incur the GA evolutionary overheads.

I'm not sure that makes it any clearer for anybody else, but thats my take on the issue ;)

Genetic Tuning ~ Natural selection, not always good.

January 7, 2005 - 9:10pm
Anonymous (not verified)

Natural selection will result in some species going extinct. It is adapt or die right. Mutations can over time result in things getting better, but they can also result in something bad. I’d hate for my process to be the one which wasn’t fit. Worse yet my system evolved into something great at one point, but resulted in a crash when a vastly different stimuli came.

It would seem that if you can’t change fast enough you’re sure to die, but your reliability won’t be that great.

It’s a neat idea, I suppose there are bounds assigned…perhaps it will never get more than a couple percent because we might not be willing to have an occasional crash/death for normal case performance gains.

It seems to me that finding "

January 7, 2005 - 10:51pm
Anonymous (not verified)

It seems to me that finding "evil" solutions would be fine; these would be pruned from the "genetic mix", and more suitable mutations would take precedence in the "breeding" of new settings.

Not in this case. Species go

January 8, 2005 - 9:36am
Nick Farrell (not verified)

Not in this case. Species go extinct because their "chromosomes" aren't good enough to let them survive. Inside the kernel this is not possible - the worst case is that every mutation/recombination is worse than the initial one, in which case the same scheduler settings are used.

I agree with the possibility of the settings for one system being suboptimal in another, but can they really be so bad as to crash the system?

I'm really unsure about this being used in a running kernel though - a lot of programs would prefer a constant timeslice to a variable one, I reckon. It'd be good if the scheduler worked for specific processes - they are more likely to have a stable "ideal" configuration. Perhaps you could then look at what processes are chewing most CPU cycles and apply that setting to the whole system...

Actually, I think certain com

January 8, 2005 - 12:00pm
Mark Williamson (not verified)

Actually, I think certain combinations of settings can still "die out", since they'll be discarded if they're not good enough. They can still reappear due to later mutations, however.

I don't think anyone is proposing reducing stability in terms of crashes - that'd be a kernel bug, pure and simple.

User processes aren't really aware of their CPU timeslices anyway, so I don't think changing it should bother them - the scheduler might want to vary timeslices in order to improve overall efficiency (but that would depend on the scheduler in use).

as it is doesn't the timeslic

January 8, 2005 - 12:50pm
Anonymous (not verified)

as it is doesn't the timeslice for a given process change with the current metholds?

It's not the processes who co

January 8, 2005 - 10:18am
Anonymous (not verified)

It's not the processes who compete and could die, it's the schedulers. if a scheduler is suboptimal, it would die, but no processes would be killed.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary