Con Kolivas wrote:
>> Looks good, thanks. Ingo's been hard at work since then and has v8 out by
>> now. SD has not changed so you wouldn't need to do the whole lot of tests
>> on SD again unless you don't trust some of the results.
On Thu, May 03, 2007 at 02:11:39AM +0300, Al Boldi wrote:
> Well, I tried cfs-v8 and it still shows some nice regressions wrt
> mainline/sd. SD's nice-levels look rather solid, implying fairness.
That's odd. The ->load_weight changes should've improved that quite
a bit. There may be something slightly off in how lag is computed,
or maybe the O(n) lag issue Ying Tang spotted is biting you.
Also, I should say that the nice number affairs don't imply fairness
per se. The way that works is that when tasks have "weights" (like
nice levels in UNIX) the definition of fairness changes so that each
task gets shares of CPU bandwidth proportional to its weight instead
of one share for one task.
It takes a bit closer inspection than feel tests to see if weighted
fairness is properly implemented. One thing to try is running a number
of identical CPU hogs at the same time at different nice levels for a
fixed period of time (e.g. 1 or 2 minutes) so they're in competition
with each other and seeing what percent of the CPU each gets. From
there you can figure out how many shares each is getting for its nice
level. Trying different mixtures of nice levels and different numbers
of tasks should give consistent results for the shares of CPU bandwidth
the CPU hogs get for being at a particular nice level. A scheduler gets
"bonus points" (i.e. is considered better at prioritizing) for the user
being able to specify how the weightings come out. The finer-grained
the control, the more bonus points.
Maybe con might want to take a stab at having users be able to specify
the weights for each nice level individually.
CFS actually has a second set of weights for tasks, namely the
timeslice for a given task. At the moment, they're all equal. It should
be the case that the shorter the timeslice a given task has, the less
latency it gets. So there is a fair amount of room for it to manuever
with respect to feel tests. It really needs to be done numerically to
get results we can be sure mean something.
The way this goes is task t_i gets a percent of the CPU p_i when the
tasks t_1, t_2, ..., t_n are all competing, and task t_i has nice level
n_i. The share corresponding to nice level n_i is then
p_i
w_i = -------
sum p_j
One thing to check for is that if two tasks have the same nice level
that their weights come out about equal. So for t_i and t_j, if n_i
= n_j then you check that at least approximately, w_i = w_j, or even
p_i = p_j, since we're not starting and stopping tasks in the midst of
the test. Also, you can't simplify sum p_j to 1, since the set of tasks
may not be the only things running.
The other thing to do is try a different number of tasks with a
different mix of nice levels. The weight w_i for a given nice
level n_i should be the same even in a different mix of tasks
and nice levels if the nice levels are the same.
If this sounds too far out, there's nothing to worry about. You can
just run the different numbers of tasks with different mixes of nice
levels and post the %cpu numbers. Or if that's still a bit far out
for you, a test that does all this is eventually going to get written.
-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
