Question: Scheduler 'Exit' or modularization of scheduler?

[Paul Robinson]

There has been a considerable amount of talk and many news articles on 
some websites because of the inclusion of the CFS scheduler either as a 
replacement for the old scheduler or instead of using the SD scheduler, 
some people apparently feel that one or the other of these is not right 
in some contexts or in some environments.  I'm not completely clear on 
what is going on or exactly what the complaint is.  But I personally 
would like to try to toss in my 0.02 Euro in an attempt to offer some 
light and less heat to the dilemma and offer a suggestion.

If my ignorance of the subject is too obvious, please excuse me, I might 
not have that much experience in the subject.  I've only been 
programming for 27 years and I hope to get better at it with more practice.

So, there are two questions about which I am wondering.   They may be 
somewhat related but the methodology for each are different and the 
method of implementation would be different.

1. Could it be possible to design the interface to the scheduler either 
that there is an 'exit' (my mainframe history precedes me) in which one 
can issue a monitor call such that the system changes to an alternate 
scheduler, possibly as part of the boot process?  Thus there might be a 
default scheduler but it is possible to invoke an alternative one.

2.  Could the scheduler be such that it be designed as a system loadable 
module rather than as a monolithic part of the code, such that the 
particular scheduler is a specific file and is simply installed at boot 
time, and if someone wants a different scheduler, they can simply create 
a new one, rename the existing one to something else, name theirs to 
whatever the scheduler's name is, then shutdown and reboot the machine?

I am thinking that the system scheduler is an integral part of a 
time-shared operating system, it would be memory resident while the 
machine is operating, thus it only has to be on disk during start up and 
is not in use while the system is in normal operation and could be 
replaced at any time (subject to the usual caveat that the system has to 
be shutdown and rebooted to cause the scheduling mechanism to be changed 
to the new one.).

If such a capacity were available, or perhaps if such capacity can be 
implemented at some point in the future, this would solve one of the 
more critical issues, since people needing more finely tuned scheduling 
facilities can use one different from the common one, or 'roll their 
own' if they need something really special.

I am also thinking this sort of a capacity would be extremely useful 
either in virtualization issues, in running other operating systems (or 
copies of Linux) as guest operating systems under Linux vis-a-vis Xen, 
or in respect to real-time versions of Linux, such that if someone needs 
to grant certain processes high priority, and the rest everything that's 
left over, then they could do that simply by writing the scheduler to 
the interface definition.

Of course, I could be completely wrong on this point and this is not a 
partitionable feature, that it's not possible to have the job scheduler 
loaded from a secondary module at boot time.  (This may be one of the 
reasons why there have been problems with non-monolithic kernels being 
unavailable for general use except in extremely limited cases.)

Or I could be wrong in that this issue isn't that important and most of 
the noise over the issue is a small and vocal minority complaining about 
a marginal and unimportant issue.   Of course, this sort of situation is 
probably the case with 90% of all traffic on usenet, newsgroups and 
mailing lists, so what else is new?

Or, and this is the big one, that this feature already exists in the 
Linux kernel and the method of scheduler invocation is already 
modularized for boot-time invokation of any chosen job scheduler.  I do 
not think is at this time the case, because if modular scheduling 
systems were currently possible, all the flamage over this issue 
wouldn't have occurred, because those who didn't like the CFS scheduler 
in place of the old one or wanted the SD scheduler, could simply 
substitute it.

I would appreciate any comments on this because I do think that if this 
capacity were available it would provide a number of significant 
features and would perhaps solve a number of problems.  (It may very 
well add new problems! But, hey, thems the breaks, all technology 
(usually) has benefits and (almost always has) drawbacks.)

--
Paul Robinson - paul@xxxxxxxxxxxxxxxx  - "A computer programmer and 
Notary Public in and for the Commonwealth of Virginia, at Large."
"Above all else... We shall go on..." _"...And continue!"_
"The lessons of history teach us - if they teach us anything - that 
nobody learns the lessons that history teaches us."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/