Hello,
here is the new scheduler implementation, based on the original approach of

SVR4, which also has various modifications in balancing and migration part

mostly based on Solaris approach (described in Solaris Internals). It

provides separate real-time (RT) and time-sharing (TS) queues, to differ the

kernel and user threads and provide POSIX real-time extensions. Please note,

that priority model (with separation of RT/TS ranges) has changed in

vmlocking branch. Also, the support for thread affinity is prepared.
http://www.netbsd.org/~rmind/m2/sched_m2.c

http://www.netbsd.org/~rmind/m2/sched.diff
Here are the results of SysBench OLTP PostgreSQL and MySQL benchmarks on the

Core 2 Duo T5500 machine (averages of 3x runs):
http://www.netbsd.org/~rmind/m2/pgsql_bench.png

http://www.netbsd.org/~rmind/m2/mysql_bench.png
I have also estimated ~4% improvement in the builds:
http://www.netbsd.org/~rmind/m2/buildkern.txt
MySQL benchmark on 4 x 700 MHz P-III Xeon (thanks Andrew for doing this!):
http://www.netbsd.org/~rmind/m2/mysql_bench_4x.png

This is a single run, and not with the latest version, thus - not accurate.
To test the scheduler, SCHED_M2 option to the kernel config should be added,

and SCHED_4BSD commented out. During the development, a lot of testing were

done, so I would tend to think that scheduler is stable, while still might be

tuned. This implementation is nohow related with the parts of SCHED_4BSD.
I am going to import it into the tree. Please review.
P.S. The name "SCHED_M2" is a result of poor imagination.
--

Best regards,

Mindaugas

www.NetBSD.org

- i'm not sure if it's a good idea to implement SCHED_FIFO in sched_m2.c.

- how about making 4bsd hook sched_pstat_proc_hook rather than

  putting #ifdef back?

- why r_bitmap is volatile?

- why sched_catchlwp is not static?

- high_pri[] should be pri_t.
YAMAMOTO Takashi

Why? Scheduling policy is a care of scheduler (sched_*.c by our abstraction),
As wrote in the note, it is a workaround for now. Those calculations should
Changed.
--

Best regards,

Mindaugas

www.NetBSD.org

i meant i prefer to have scheduling class abstraction.
YAMAMOTO Takashi

Separate classes like in Solaris or latest Linux? I was thinking about this

way, and few things came to my mind:
- Despite that we will probably stick only on one implementation, such

  abstraction complicates the possibility to have more than one scheduler.

- The current version of SCHED_M2 is very light, and separation of classes

  would not simplify anything, perhaps vice-versa.

- It is useful when there are many classes, and the complex ones, like in

  Solaris. However, I am not sure if we should go with this way. There

  are a lot of flexibility and dynamism in Solaris dispatcher (scheduler),

  but it is quite bloated, and IMHO complexity vs benefit is questionable.
At least at this moment, I would like to have the light versions of RT, TS and

FS (fair-share) classes in SCHED_M2. In case it gets huge - we can always

change the abstraction in future, but perhaps it is not worth doing now?
--

Best regards,

Mindaugas

www.NetBSD.org

The above graph from the 4x cpu system is with sysbench run remotely. When

run locally on the same 4x system SCHED_M2 delivers a massive improvement

in throughput:
	http://www.netbsd.org/~ad/m2-local.png
Really nice work!
Andrew