Subject: Re: Implementation of SCHED_M2 scheduler
To: None <firstname.lastname@example.org>
From: Mindaugas R. <rmind@NetBSD.org>
Date: 10/09/2007 06:13:08
email@example.com (YAMAMOTO Takashi) wrote:
> > 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?