Code for review.. threads vs. the scheduler

Julian Elischer julian at
Wed Aug 11 18:50:22 PDT 2004

Here is a version of the diff that is pretty much functionaly equivalent
to the current system (and
almost identical to patches  (c) and (d)  (*) but it takes it  astep
further in that teh struct kse has been
removed from proc.h and made a private structure within each
scheduler.   Nothing outside of the 3 files
kern/sched_4bsd, kern/sched_ule.c and kern/kern_switch.c (which is now
included into the schedulers
rather than linked with them) even knows what a struct kse looks like.

(*) these patches were not widly distributed.

The patch is available at:

At this point each scheduler can be alterred almost completely
independently of the other as long as the
fields in the kse that are referenced in the common code in
kern_switch.c are not renamed or removed.

-where to from here....

The next logical step is to move the fields within the thread, and
ksegrp structures that reference kses into
the scheduler specific extensions to these structures so that not even
those references are externally visible.
This would make the queues and lists that are used to hang KSEs off
also private information for the
scheduler, allowing schedulers to have their own private queueing
architectures without having to expose them
to anything external..

The NEXT step after that is to move all the fields in the KSE structure
into the thread's scheduler-private
structure (td_sched) and rename it a "kse" to stop the need for massive
mechanical renaming.
Since every thread has one of these, all the KSE allocation code just
vanishes as do the restraints that they
hold on code due to locking requirements etc.  sched_ule and sched_4bsd
don't change much at all.
"concurrency control " is switched to use a simple pair of counters.
(available slots and total slots (concurrency)  per ksegrp.  Except for
that change, even kern_switch.c
remains mostly the same and the KSE structure as we know it has
dissappeared entirely (though
its name is passed to the td_sched structure for diff-reduction purposes..

when this is done we have a scheduler interface that COMPLETELY hides
within it
how and where  threads are queued, or in fact if they are queued at all..
(A Monte-Carlo scheduler may use a completely different scheme based on
probablilistic scheduling..)

It should also be a lot more reliable and I suspect that the morphing of
the KSE structure into something
that is always a part of the thread MIGHT also fix the Preemption hang
we've been seeing.

Sched-ule and sched-4bsd can then be experimented on a lot more freely
without worrying about
unintended changes to teh other. Especially if one of the schedulers
takes a complete copy of
kern_switch.c instead of including it.. Indeed a new scheduler can be
added with a single file,
and no other edits, allowing people to experiment with their own
schedulers much more easily.

Julian Elischer wrote:

> Here's an "up to date" version..  (version d)
> has been seen running thr and kse threaded programs.
> Mike Makonnen wrote:
>> On Mon, Aug 09, 2004 at 01:11:00AM -0700, Julian Elischer wrote:
>>> regular thread_exit() will do teh job.
>>> mtm.. can you see if this still works?  I don't have the rignt setup 
>>> to test it now..
>> Sure, I can get to it tonight, but it would be a lot easier if
>> you could send a patch against the current tree :)
>> Cheers.

More information about the freebsd-current mailing list