yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
quoted text
> > Why? Scheduling policy is a care of scheduler (sched_*.c by our
> > abstraction), not dispatcher (kern_synch.c or anything outside).
> 
> i meant i prefer to have scheduling class abstraction.

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