lkml.org 
[lkml]   [2007]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectQuestion: Scheduler 'Exit' or modularization of scheduler?
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@paul-robinson.us - "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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-07-31 21:33    [W:1.441 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site