Re: Code for review.. threads vs. the scheduler

Julian Elischer wrote:

>
>
> 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:
>
> http://www.freebsd.org/~julian/e.diff
>
> 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.
>
Hi there,

did anyone actually test this patch? Maybe a change of subject line 
might help get some attention..

I am very tempted to test it, if there is any chance that it might, in 
its current form, help stabilizing things on -current. Especially with 
the preemption issues in the back of my head..

/Eirik