Re: [Lse-tech] Re: [PATCH][RFC] Proposal For A More Scalable Scheduler

[Davide Libenzi]

On Wed, 31 Oct 2001, Mike Kravetz wrote:

> On Tue, Oct 30, 2001 at 09:29:41PM -0800, Mike Kravetz wrote:
> >
> > I'll kick off the all important 'kernel build benchmark' and have
> > some results tomorrow.
>
> --------------------------------------------------------------------
> mkbench - Time how long it takes to compile the kernel.  On this
> 	8 CPU system we use 'make -j 8' and increase the number
> 	of makes run in parallel.  Result is average build time in
> 	seconds.
> --------------------------------------------------------------------
> # parallel makes       Vanilla Sched   MQ Sched         Xsched
> --------------------------------------------------------------------
> 1			 56		 55		 61
> 2			105		105		105
> 3			156		156		154
> 4			206		206		205
> 5			257		257		256
> 6			308		308		307

Thanks Mike,

I'm pretty happy with this coz it shows that the current process migration
scheme does not suck so much, only a bit.
Kernel builds are not a stress test for the scheduler, when I run a -j 2
on my 2SMP I got a vmstat cs~= 500
I'm currently working on different schemes of process balancing among CPUs
with a concept of tunable hysteresis to try to give the ability for users
to setup the scheduler behavior for their needs.
What is happening with the volanomark with the proposed scheduler is that
one task start creating the requested number of threads and the new
created thread is very likely going to sleep after its creation.
So suppose that the main test task run on CPU0 ( rqlen[0] == 1 ),
get_best_cpu() is going to return 1 coz it's probably the first free.
But the new task is going to sleep/"wait for some event" before the test
task on CPU0 will call fork()/clone() again.
This will create a heavy process distribution over CPU1 that, when the
real test begin, will not find any idle reschedule to have the opportunity
to balance.

- Davide