- They are not optimized towards a typical 'average' user.
This is because we don't have average users and because
there's no way to know if a certain optimization breaks
stuff for other people.
[ I once spent 4 days tuning some patch of mine, after
that it worsened performance on large, small, networked
and I/O overloaded systems :), since then, I don't really
tune, but have the system make the balancing itself ]
- The settings are almost all flexible, with the different
settings interfering with eachother so that the system
might just become balanced after some time...
OTOH, it might not and the system could get into some
jojo effect :(
- There really isn't much difference between playing
Quake and doing number crunching. Both are basically
number crunching apps, but Quake places a high I/O
load on the system whereas rc5des doesn't.
[ I know, people are going to disagree with this, but
you _can_ split load in it's different characteristics
(CPU, mem, I/O, net) and then give a number to each
of these things. Then you optimize your system to handle
all loads as good as possible. This way there's a good
probability of handling a mixed load efficiently too... ]
> I do not think it is terribly difficult to implement some sort of a AI
> optimizing system, it does not have to be inside the kernel. As long there
> is a way to read and change the parameters, it can be done.
The values for the MM subsystem are in /proc/sys/vm/, please
feel free to optimize your system further...
I am really curious what the optimum settings for different
systems and loads are...
The reason I am choosing the MM subsystem is because:
- it's almost fully sysctl tunable
- it's completely documented
- the MM subsystem is easy and sometimes fun to tune
- it's the bottleneck on most Linux systems I've seen,
this means we could use some tuning
- I am one of the MM people, and I'm trying a shameless
plug in order to get some more information on performance
- once I know which parameters differ the most between systems,
I can build a little self-tuning code into the kernel in order
to have every system run near-optimal
- if I see some values that are optimal on nearly all systems and
are different from the current values, I'll adjust the defaults
In short, if this project is going to happen, it won't be a
wasted experiment, but we'll act on it and adjust the kernel
accordingly...
> Two possible problems are:
> the time consumed during the production phase by the AI implementation
> should be as little as possible, and the AI implementation would never
> guess certain wishes of the user. Pherhaps the owner of the system is a
> selfish b. and would wish to give as little as possible time to the other
> people using his system. This would require a completely different type of
> AI.... or just user input for setting up the boundaries. The good thing is
> that if a computer is used for one task only, the system would optimize
> itself to serve this task completely, and the production phase would cost
> almost nothing (only checking whether the pattern has changed).
User input would be a good thing. After all, the computer
is there for the user(s)...
It would also simplify the AI algorithms, so that the AI
program won't have too much influence on the system it's
trying to tune.
OTOH, there should be some objective measurements too,
look at the output of 'vmstat' and 'procinfo' for hints
on what I mean.
> Anyway, little do I know of kernels, so most of what I just said is just
> waving hands. That is why I posed the question in the first place, I have
> no clue, but would love to play around with something like that.
The documentation for the MM subsystem is (for 2.1 kernels)
in /usr/src/linux/Documentation/sysctl/vm.txt.
Other things can be discussed by private e-mail...
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu