Re: [ck] [REPORT] 2.6.21.1 vs 2.6.21-sd046 vs 2.6.21-cfs-v6

William Lee Irwin III
2007-05-03T04:35:05Z

>> 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.

On Thu, May 03, 2007 at 06:51:43AM +0300, Al Boldi wrote:
> Is it not biting you too?

I'm a kernel programmer. I'm not an objective tester.

It also happens to be the case that I personally have never encountered
a performance problem with any of the schedulers, mainline included, on
any system I use interactively. So my "user experience" is not valuable.

William Lee Irwin III wrote:
>> 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.

On Thu, May 03, 2007 at 06:51:43AM +0300, Al Boldi wrote:
> Ok, but you can easily expose scheduler unfairness by using nice levels as
> relative magnifiers; provided nice levels are implemented correctly.

This doesn't really fit in with anything I'm aware of.

William Lee Irwin III wrote:
>> 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.

On Thu, May 03, 2007 at 06:51:43AM +0300, Al Boldi wrote:
> chew.c does exactly that, just make sure sched_granularity_ms >= 5,000,000.

Please post the source of chew.c

-- wli