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