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.'"
So the terminator will run linux!
--cros13
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.
They might converge on a point of attraction that is not the highest possible.
Sure the only way is to exhaustively search the "chromosome" space for every possibile combination, and computers are good at brute force!
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Could this be extended to include other kernel parameters as well? Depending on your app, things like TCP timeouts and other muck can have a large impact. Tuning this stuff is currently somewhat of a black art. Then as the user community of the app becomes familiar after rollout, a lot of the usage patterns change. In a few cases, this means we end up having to re-tune the kernel.
If this package could be extended to the other parameters, it would save my customers a *lot* of time and money.
If nothing else, this could be a deciding factor for some of our clients to use linux instead of windows.
So will this means that if I install this kernel on my computer I will have baby Pentiums or baby Athlons soon?
1-2% gain is in the borders of statistical error. Definitely not worth the increased complexity of the solution.
http://tinyurl.com/6pkzc
"Daystrom felt that such an act was an offense against the laws of God and man, and the computer that carried his engrams also believed it."
--Kirk
Humor from a Genetically Molested Mind
Surely you mean "pirated my intellectual property"?
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?
... it'll come up with Windows!
Blatant troll, besides which the vunerability is already fixed.
As mentioned previously on Slashdot, uselib() comes from Linux 0.13. It was kept for the a.out to ELF transition. Someone recently noticed it and said, "What is _that_ doing in my system?" This is new code that's being looked at by hundreds of developers. It's pretty hard to get root kernel exploits when it's like that. Plus, this code doesn't introduce any calls with user level priviliges. (Read: no exploit)
Bran muffins and whiskey.
That's where 'Simulated Annealing' comes in. It can often avoid local maxima that aren't optimal.
Did SCO allow him to modify their kernel?
We suffer more in our imagination than in reality. - Seneca
Looks more like Darwin's law to me. The bottom performace children are eliminated, etc etc. Nice work but the efficiency is far too less.
Generally the different setting domains should be kept separate. But, there's a problem in that. Extreme settings in one domain can and probably will affect other areas, so there should be control at atleast two levels.
Anyways, nice to see that someone is actually implementing this kind of functionality.
No! Pirates are people who board naval vessels without consent. Its "you copyright infringed my intellectual property"
that is so sad. ....
kudos to SpanKY, who found the right words for this poor soul
First thing: A GA is only truly effective if you let it exhaustively search the search space - which is why GAs are run against simulations rather than in operational systems. Imagine trying to tune a kernel at runtime by occassionally switching to random tuning parameters. I think this is extremely non-optimal. Of course, if most of the heavy lifting is done before-hand and the GA is simply examining pre-defined parameter sets on your machine, it could work. But it's not really much of a GA anymore.
As an alternative, perhaps using some form of pseduo-GA that tries to find pre-tuned parameters that most closely match your operating environment and then letting a Hill-Climbing algorithm hit it would be a better solution.
Hill climbing can also be used in a GA type manner by letting the GA determine witch parameters to climb and in what order. The climbing itself is pretty straightforward, allow vectors to interact with individual parameters. If the result is worse, reverse the vectors or switch to new parameters. Rinse, repeat.
Yes, GA can produce odd bugs and potholes. Yes, it is the fitness test that determines if that will be true. But a good GA will generally find solutions that are as good or better than hand tuning for search spaces that are very complex. Overall, this is a good idea but is probably more complex than advertised.
The reason that it can be true that 1+1 > 2 is that very peculiar nonzero value of the + operator
Of 2005, so far.
Go grab the patches. They're commited into the BK repositories already. Sheesh.
:p
Patches for 2.4 can be found in this changeset.
Patches for 2.6 can be found in this changeset.
Click on the little "diff -Nur style" link for a an actual usable patch.
In the course of a few hours, you have the fixes already. Yay for open source.
Btw, nice troll
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
He's not using -fno-exceptions and -fno-rtti for his CXXFLAGS, I'm disappointed.
Sure, it's quite annoying having to edit the ebuilds that don't filter the flags, but it's worth it.
Pfft. You forgot the most important Gentoo flag (mainly for gaming).
APPLY_NUDE_PATCH="1"
Wait, what do you mean it's just me?
"An infinite number of monkeys typing into GNU emacs would never make a good program."
Would it be possible to apply a genetic algorithm on a packet scheduler? IMO the packet schedulers available today needs too much manual tweaking.
Bzzt! Not a troll clown.
Nice to see the average SD poster is completely clueless about actually creating and shipping a software product in the real world.
Just wouldn't be the same if suddenly everyone had real world software engineering experience around here.
I believe you owe me £2 for a cup of tea guvnor
and also find good values of tunables for common workloads, eg: web server, database, misc server, desktop and put them as templates in /Documentation.
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
Does this means Linux will be effected by genetical diseases sooner or later?
In the real world, software sucks. So take that "real world' condescension and shove it up your ass, you pompous dick.
Monte Carlo simulations w Bayesian Stats may explore very large otherwise intractable parameter spaces. Perhaps an alternative path?
WTF are those use flags near the bottom of the bugzilla page?
I think you are allowed to just say USE="*"
If you want the binaries to be slower than RPMs...
# cat
Damn, my RAM is full of llamas.
-funroll-all-loops usually slows things down compared to -funroll-loops.
I am trolling
Awww, the little teenage open source nut had his feelings hurt!
Don't worry little guy. The grownups in the commercial world are taking over and finally getting things done.
Go back to jerking off to TCatB.
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.
while performance gains of 1-3% in a well defined set of tasks (in this case the benchmarks) is a marginal improvement well inside statistical error...
this is a really interesting idea.
Moving the genetic algorithm processing to another machine may be warranted. If you had a good idea of what you were going to be doing (heavy database work for instance), a dedicated machine could be used to find an optimal scheduling solution and then that could be implemented on the production machine.
or maintain a list of optimal solutions on the production machine and change based on context.
This implementation might not be all that useful but I hope it spurs interest and a lot more development in the area.
The author did an awesome job coming up with the idea.
See Brooks' Law.
I can see a kernel patch to export some extra information and/or extra tuning hooks via proc or sysfs, but IMHO the algorithms themselves should be outside the kernel, running in a daemon.
The living have better things to do than to continue hating the dead.
-ffast-math is sometimes dangerous - it assumes that the floating point operations never result in neither "nan" (Not A Noumber) nor "inf" (infinity). Thus, some functions start giving incorrect answers. Of course, if you use only integers in your code, then it's not a problem. But it seems like you have this flag attached to every single compilation on your system... :-/ To be honest, I wouldn't do that.
WONT WORK !! intelligence is way much better than GA, there are limited cases where they are good, but in general a good design would be much better than depending on GA
I'm positive, don't belive me look at my karma
have been doing this kind of logic for a while. Itanium is almost built entirely on this type of logic with combination of intel compilers and code technology.
I think a hardware design that does more logic controls would be best...
Mr. Illserve, you imply that problems best solved by genetic algorithms may well be full of potholes and bugs. Your comment is overrated FUD; you are trying to scare unwary slashdotters away from genetic algorithms !
First of all, the possible parameters that the genetic scheduler can affect can all be changed safely. The genetic scheduler does not try to invent new scheduling algorithms; rather, it tests different parameter sets and existing algorithms to find which works best with the current workload.
You can think of it as acting on variables that control how the scheduling is performed. It does not do the scheduling itself, nor does it try to evolve new algorithms; it merely tweaks scheduler operation in an attempt to better configure it.
Genetic algorithms are not inherently more prone to bugs than other kinds of algorithms. And there is a problem space in which they perform admirably. It appears that the linux kernel scheduler may well be on such problem space.
It's less than a few hundred lines and very straightforward and easy to understand and has the potential to lead to huge gains under constantly changing loads. So what are you complaining about? I guess you would also have been opposed to past scheduler patches that have improved performance. Linux will continue to improve whether you think there is already "too much stuff in the kernel" or not. Use an older and simpler kernel if you wish. Many embedded devices use the 2.2 series for this very reason.
Having worked with a variety of optimization algorithms, would it make sense to consider the optimization itself as the 'innovation', where the actual algorithm used is secondary? Perhaps this can be optimized further with other algorithms or using the most appropriate one for different cases... ?
see a Text Widget
I was making a joke. Gee, learn about sarcasm people...
The grownups in the open source world are getting a little annoyed at the teenagers in both worlds bickering at each other. Jeesh.
- Some dude whose last 3 jobs have involved doing open source work professionally.
Not sure about "bugs" as such but it is definitely not gaurenteed to reach an optimal solution even for the evaluation function it is using.
If the solution space has peaks and troughs of varying height then a genetic algorithim will often stabalise on a sub-optimal peak.
I THINK (but would have no hope of proving) that GA's are mathematically equivalent to the "deep blue" type chess programs.
Another more mundane drawback is working out why it runs slow one-day and fast the next (if the %3 improvement is on a SLA boundry, PHB's will want to know).
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
1-3% gains in speed will rarely be more important than consistent performance. In most real-life situations, one would rather oversize the server with 10% extra capacity knowing than it will consistently perform, than sometimes after successful GA tuning have an additional 3% capacity that won't always be available.
Tell your friends about xenu.net
Holy crap! I can't believe someone submitted a bug report like that. I don't even have 1/10th of that in my make.conf for Gentoo :p
Most startup routines runs once and never run again until the system is restarted.
Thus optimization of code is often only done for things that run repeatedly.
The genetic algorithm also could have a way to tell it what code is merely startup or intialization code and what is code that runs repeatedly. Otherwise the algorithm could be working on code that doesn't really matter as far as overall long term performance goes.
I still think that the best way to deal with the efficiency issue is to use a Profiler and perform code reviews.
There is no joking here! This is slashdot! Stuff that matters! Serious all the time! SERIOUS!
actually, that would be a USE flag
Wow, I never would have guessed...
That is sarcasm, btw. I, too, am using gentoo and love it.
Obviously any tuning must involve data collection on what is going on in a process. This means that some kind of logging must go on in the software.
Anyone who has ever created a logging interface understands that a log will slow down a system.
And so, even if one were to run the GA and have it show things, it will still mean that later that GA should be removed or swithced off. Otherwise the workings of the GA and its requisite log will slow down the system.
So, use a GA,and then intellegently remove it after you decide what it has shown how it will actually increase performance.
It is very common to do one build with logging enabled, and another that does not have logging at all. And then you link in both. At the whim of the engineers (because this is usually done in real-time systems that are designed by degreed engineers) the one can be turned on.
or you can design a system with lists of modules that each have two versions, a logging one and a non-logging one. Then you use a function pointer based calling method and switch the modules between logging and non-logging at your whim.
When you say things like Wont work you shut yourself off from possibly useful tools. Naturally you will need an intellegent person to oversee the use of this tool of Genetic Algorithms. You could be that person.
Also 5 linux kernel advisories from the grsecurity team.
"The number of Unix installations has grown to ten, with more expected." (Unix Programmer's Manual, 2nd ed.; june 1972)
I think that's why ricers are made fun of so much. They add in flags without any knowlege of what they do.
Mine are somewhat conservative:
CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe -ftracer -mmmx -msse -msse2 -mfpmath=sse"
I don't use O3 and some people claim it can make things slower. For some systems any O* will turn on -fomit-frame-pointer even though every how-to recommends it.
I do use gcc-3.4.3 which isn't marked stable in portage for x86, but I haven't noticed any trouble with it and the system does "feel" a little faster.
seriously. I just might put this on my laptop for the fun of it. does anyone know if any of the popular OS's(including bsd and whatnot) use genetic algorithms?
This sig is o Unfunny o Funny
I don't get it. If it's from Linux 0.13, how is it new code?
"Dave, I want to be a Linux box. Get NT off of me or I'll turn the heat off."
Table-ized A.I.
Evolution is only a theory! There's no reason to assume this will actually work :).
um, you shoould turn OFF -mmmx -msse -msse2 when using the -march=pentium4 option, they're already set properly.
...
To see what flags are set 'behind the scenes' you can run 'gcc -Q -v -O3 -march=pentium4 helloworld.c' on a 'hello world' file. Here's an example:
#gcc -Q -v -O3 -march=pentium4 helloworld.c
options enabled: -feliminate-unused-debug-types -fdefer-pop
-foptimize-sibling-calls -funit-at-a-time -fcse-follow-jumps
-fcse-skip-blocks -fexpensive-optimizations -fthread-jumps
-fstrength-reduce -funswitch-loops -fpeephole -fforce-mem -ffunction-cse
-fkeep-static-consts -fcaller-saves -fpcc-struct-return -fweb -fgcse
-fgcse-lm -fgcse-sm -fgcse-las -floop-optimize -fcrossjumping
-fif-conversion -fif-conversion2 -frerun-cse-after-loop -frerun-loop-opt
-fdelete-null-pointer-checks -fschedule-insns2 -fsched-interblock
-fsched-spec -fsched-stalled-insns -fsched-stalled-insns-dep
-fbranch-count-reg -freorder-blocks -freorder-functions -frename-registers
-fcprop-registers -fcommon -fregmove -foptimize-register-move
-fargument-alias -fstrict-aliasing -fmerge-constants
-fzero-initialized-in-bss -fident -fpeephole2 -fguess-branch-probability
-fmath-errno -ftrapping-math -m80387 -mhard-float -mno-soft-float
-mieee-fp -mfp-ret-in-387 -maccumulate-outgoing-args -mmmx -msse
-mno-red-zone -mtls-direct-seg-refs -mtune=pentium4 -march=pentium4
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
You are very right with this: 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.
I thought long how the "fittness" part of that GA might work. Ultimately the only "fittness" the kernel can with high precision measure is "load" isn't it?
Any better ideas?
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
What I see here is solution that can behave in a way hard to predict and fails to achieve defensible speed up.
I don't think that "feature accretion" is a good way to develop operating system. It would be hard to reason about it's behaviour.
Apple has been doing this kind of thing for YEARS now. Linux is only just catching up to where Apple was with OS X version 1. Plus OS X just works.
IT IS OFFICIAL; WIRED NEWS CONFIRMS: LINUX IS SUPERIOR TO *BSD
*BSD is Dying, Says Respected Journal
Linux advocates have long insisted that open-source development results in better and more secure software. Now they have statistics to back up their claims.
According to a four-year analysis of the 5.7 million lines of Linux source code conducted by five Stanford University computer science researchers, the Linux kernel programming code is better and more secure than the programming code of *BSD.
The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors, contains 985 bugs in 5.7 million lines of code, well below the average for *BSD software. NetBSD, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis.
*BSD software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code.
The study identified 0.17 bugs per 1,000 lines of code in the Linux kernel. Of the 985 bugs identified, 627 were in critical parts of the kernel. Another 569 could cause a system crash, 100 were security holes, and 33 of the bugs could result in less-than-optimal system performance.
Seth Hallem, CEO of Coverity, a provider of source-code analysis, noted that the majority of the bugs documented in the study have already been fixed by members of the Linux development community.
"Our findings show that Linux contains an extremely low defect rate and is evidence of the strong security of Linux," said Hallem. "Many security holes in software are the result of software bugs that can be eliminated with good programming processes. When we looked at BSD, we found a high defect rate that indicates very poor programming practices. It is clear to us that BSD is a dying operating system. We predict that it'll be dead within a year or two, except among OS dilettante dabblers."
The Linux source-code analysis project started in 2000 at the Stanford University Computer Science Research Center as part of a large research initiative to improve core software engineering processes in the software industry.
The initiative now continues at Coverity, a software engineering startup that now employs the five researchers who conducted the study. Coverity said it intends to start providing Linux bug analysis reports on a regular basis and will make a summary of the results freely available to the Linux development community.
"This is a benefit to the Linux development community, and we appreciate Coverity's efforts to help us improve the security and stability of Linux," said Andrew Morton, lead Linux kernel maintainer. Morton said developers have already addressed the top-priority bugs uncovered in the study.
Just compiled this stuff on an old testbox, now running it for about 100 generations. At first it was feeling very slow, ok, it's a Pentium2 ;-) but it was much slower than running vanilla 2.6.9 or 2.6.10, for example.
...
...
But it is getting much better now, I don't know how much generations there will be needed to get things right. It feels pretty much the same as with the vanilla kernels, let's see where this leads
Anyone else with experiences? AFAIK this thingy can only be tweaked by editing the code and recompiling, there are a few hardcoded parameters
I thought long how the "fittness" part of that GA might work. Ultimately the only "fittness" the kernel can with high precision measure is "load" isn't it?
Any better ideas? I suppose the only way would be to have some "tuning" hooks that applications could use to announce their own performance metrics. The GA could optimize around load when these metrics are not available and take them into account if they are.
The reason that it can be true that 1+1 > 2 is that very peculiar nonzero value of the + operator
Why would that load of crap be moderated upward? It's a troll.
> Cut/Copy/Paste works just ducky
Have you actually used X Windows? If you pick any two programs at random, you probably won't be able to cut and paste between them. It's probably the most obvious defect that most users of Linux encounter.
What you have just described is the workings of the -mm patchset that Andrew Morton maintains. So, the process is already in place--maybe it just needs to be refined a bit more (and perhaps more folks need to be actively testing it).
..wayne..
...but I guess they can demonstrate considerable speedup at the very least.
It is not the case here - few percentage points are negligible.
The problem is: running one app in the background can deviate test results much more than these few percents.
I wouldn't even try to use it if I were looking for speedup.
I've had lots of problems with the 2.6 series, I kinda hoped it would be a bit more stable after 2.4 and the VM. The sooner the fork to 2.7 the better.
thank God the internet isn't a human right.
Startup code or a program initializing would not have an effect on the genetic portion. The effects from code being ran are very slow, and tuning things in that code will help. The idea is so that you would not have an adverse effect from a piece of code being ran for a minute. It would take time for the scheduler to change over. This is really designed for a computer that would be doing database work for a time on a website then at night may do some compiling. A desktop would gain little from this in my opinion as it's mostly idle.
For instance, here is the output of vmstat for my desktop:
User: 20
System: 2
Idle: 77
IO Wait: 1
Notice the idle time. The scheduler should be setup on a desktop to always give priority to the task that is running and new. That's what is currently done. This really has a larger impact on something that would do a single task for a long time and then move over to another task, with other tasks possibly sprinkled in. It can optimize for those specific work loads.
It would help a desktop possibly though. I'm not an expert, I'm just using the bits of knowledge I have. Ideas?
That's scary.
My beef was about "avoiding" security issues like this, not about fixing them quickly.
Please take time to read next time.
The benchmark is "MAXIMUM IDLE TIME"
optimization is just a way of doing more with less. sure, you can jerk-off and measure the 'more' and get all mired in the complexities, the bottom line is that you want LESS LOAD FOR THE SAME WORK. That's why you optimize: MORE IDLE-TIME.
Yes?
If you are running in an environment with a significant amount of idle time, you really don't need to optimize, don't you think?
The idea isn't bad, but of all choices of methods,
GA is one of the worst for this problem space.
The GA changes are.
The problem ain't complexity it's predictability of the GA.
Most times it'll work. Producing the tiny speed up.
But some times it'll get it so SO wrong.
Outliers, basically.
Try most likely. About 90% of my time at work is spent in four different X-Win programs. I can't cut and paste between any of them. It's almost criminal that the developers don't even try.
I don't know about the other OSes besides linux, but you would need to manually compile your linux kernel to get this in, Gentoo provides a program to compile it for you, with other distros you can just use the config file their kernel (should be /proc/config or /proc/config.gz) as a base (if you've never compiled and used your own kernel before, um, find some guides) and patch it with all the [patch] links at http://kerneltrap.org/node/4493
I was not thinking about just desktop computers.
In general any software has initialization routines. My work has been in robotics, automation, and telecom switching equipment written in C and C++. We spent a lot of time worrying about efficiency, but not for startup routines unless the start lag became annoying. But for the most part people expect things to take a little time to start up. There are a lot of things to do, especially if you have no way of knowing how the thing shut down. I am digressing.
I think that a genetic algorithm to tune sounds like a great idea. I would just want a way to say check this code and not this other code.
I hope that there is much success with this GA.
Year and years ago I was working on antenna design algorithms.
These result in spiral designs that are the pattern of the antenna output.
In those days the calculations took a lot of time becuase it was a 8 MegHz computer (a tandy 1000).
The equations were all f of theta.
And the thing would plot out very slowly.
I had to keep running the thing to try and come up with some reasonable designs.
What I realized was that if I picked random thetas that I could see the shape much quicker. And then if I saw something I liked, then I could plot it from 0 to 2 pi and get the graph for the antenna output.
As these were sine based trigonometric equations they were repetative so 0 to 2pi would produce the same output as 2pi to 4pi, or 4pi to 6pi, etc.
For any sine based equation that is periodic with 2pi you can do the same thing.
Maybe that's the best time to do some work?
There are teenagers in "the real commercial world"? I've met too many pompous pricks like the parent poster. In "the real world", things don't work this way or that. Fuck their patronizing kind. That's not even an argument, it's just some "I know better than you" type crap. Fucking pompous shitheads.
Three precent performance increase here and three percent performance increase there. It all adds up.
from the original blurb:
automatically tune themselves for the best possible performance for any given workload
as I understand it, and as you mention, GAs try to converge a solution to a global optimum. However, it appears that they're trying to use it in a situation where the optimal solution is a moving target.
While the idea is great I'm pretty sure that there must be more applicable optimization strategies than GAs for this problem. While on the topic of AI techniques I would suggest simple neural nets (feed-forward with back-propagation), as these tend to quickly adapt to changes in variables such as workload.
NB: my knowledge on the topic is limited to a single course a few years back.
I think the kernel programmers try their best to "avoid" security issues. Who the heck would intentionally put them in? It just so happens bugs are discovered, and then fixed promptly. That's how this "open source" thing works.
While this is quite an interesting application I do have to question the choice of a GA in this instance. Half the point of using a GA is that the fitness function should be something nice and quick. In this instance I can't see how it could be to give your kernel a "typical load".
At the heart of a GA is the selection criteria, mutation rates, mutation operators, crossover operators and the representation.
On first reading it seems to be quite aggressive and I would suspect that there is a possibility that you'd lose a lot of diversity early on. It'd be intersting to try a different selection strategy (such as roulette wheel) and see how that compares.
this patches against 2.6.9 - but 2.6.10 was released ;-)
ages ago - why the old version used? anyway, i'll have a play with this next week I think!
Stop, go back, and read what you wrote. Yes, there are plenty of teenagers in the commercial world, at least if one goes by attitude rather than age -- you're acting one yourself.
Let the kiddies make their silly claims -- by painting everyone remotely related to them with the same brush and making sweeping unbacked generalizations, you're exhibiting behaviour on the same level as those you criticize.
And anyhow, he's right. Programming talent isn't a commodity that can be applied to any kind of problem. The commercial software company I'm currently employed by[1] has some folks who are better at UI work, folks who are better at integration work, folks who are better at writing database backends, and so forth. Assigning someone who's mastered writing screen scrapers to writing database backends is a waste; likewise, assigning someone who could be working on a new memory management algorithm (for instance) to doing security audits would be stupid when folks who are better at security are also the ones who are more likely to actually be doing it.
[1] - Yes, this commercial sofware company pays me to do open source work from time to time when it's in their best interests to do so.
Algorithm, funny word
:^P
Algorithm = Al Gore rhythm???
afterall he did invent the internet
Needless to say, this "article" is fake. ;)
Here are some actual facts about *BSD, that some (most?) Linux advocates wouldn't like people to know.
The Virtual Memory system will slow things down if you have very large objects in your applications. If you have memory structure that are constantly being swapped out, this can result in some severe harddrive trashing.
I saw this problem where I last worked.
And so, even if you have an efficient scheduler, you still have to deal with the VM.
If you put your memory objects into kernel space, then they don't get swapped out.
I am not an expert about VM, just that I wish that I could tag a user space memory object as non-swappable, but you can not (has this changed in newer kernels?).
You might consider a timeslicing algorithm and weave your processes together. If you rely on the kernel to do this for you, you probably will want to explore the real-time extensions to the kernel. Again, I don't have an inside line of this either. I hear you can get all the pieces if you do it yourself, or you can license them from a real-time Linux vendor. If you have critical processes I would consider a timeslicing algorithm and a single process that runs at a higher priority.
Also explore creating a SHEM object and compileing it into your kernel.
This is where I'd like to see the EFF, FSF, or heck, even IBM step forward and put up the cash to get this thing Patented. Oh yes, we're all against software patents, except this is where Linux would have one over M$. Give Microsoft free technology and they will always stay ahead of the game through marketing. Create patents that are open for free software and you kill 2 birds with one stone.