Re: Question: Scheduler 'Exit' or modularization of scheduler?

Paul Robinson,

Solaris's SunOS SVR4.x has a modular schedular / dispatcher,
however, I believe that the time share dispatcher is
actually a frozen-base and is not replaceable. I do
believe that some of its scheduling characteristics are
modifyable.

IT is my understanding that CFS is the new schedular,
however it is separated from the RT (real-time) FIFO and
RR schedular.

Currently, I have a initial suggestion to lkma to see if
their is any support of a interactive task class. It allows
a root user to classify a set of tasks as interactive.
If their is acceptance, I plan to propose a patch/ set of
changes to support this new task class by the end of Aug.

IFF, then maybe in the future...
Paul Robinson, if you feel that you are up to the task
of modularizing the schedular / dispatcher to do what
you think should be done, I would suggest submitting
a prototype to Ingo, et al and see what the response
is..


Mitchell Erblich
----------------

Paul Robinson wrote:

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/

-
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/

Relevant Pages

  • Re: [patch] CFS scheduler, -v6
    ... modularity patch for mainline as opposed to porting current mainline to ... to it without significant code impact to the core scheduler code. ... People seem to be confusing scheduler policy with a modular framework. ...
    (Linux-Kernel)
  • Re: [patch] CFS scheduler, -v6
    ... CFS is a huge step into a modular and hierarchical scheduler design, ... mainline, SD, or nicksched without significant core scheduler impact. ... CFS doesn't have all that much to do with scheduler classes. ...
    (Linux-Kernel)
  • Re: Fully and Partially pre-emptible kernel
    ... > What is that part of the kernel that will pre-empt the scheduler and again ... partially due to some odd bits of Solaris ... etc. is known as the "dispatcher". ... interrupted by high-level interrupts (for example, ...
    (comp.unix.solaris)
  • thread/process & memory management source code
    ... where the code for FreeBSD's thread/process & memory management are? ... Specifically, where the dispatcher and scheduler is implemented, ... where the dynamic storage allocation algorithm is implemented(I'll try ...
    (freebsd-arch)
  • thread/process & memory management source code
    ... where the code for FreeBSD's thread/process & memory management are? ... Specifically, where the dispatcher and scheduler is implemented, ... where the dynamic storage allocation algorithm is implemented(I'll try ...
    (freebsd-hackers)