Patches for threads/scheduler abstraction.

[Julian Elischer]

On Wed, 16 Apr 2003, Jeff Roberson wrote:

> 
> On Wed, 16 Apr 2003, Julian Elischer wrote:
> 
> >
> > OK I will send them shortly.
> >
> > These patches are NOT CLEAN
> > by which I mean I have not done any tidying up yet.
> >
> > It is still in the "cat dragged this over the fence" state.
> > However it does compile cleanly with only four files knowing what a kse
> > is (Not counting ULE, I have not touched ULE yet) (and I would actualy
> > rather that you did.. you understand it better).
> >
> > !!!!!!I have not tried to RUN this yet!!!!!!
> > The files that know what a kse is are:
> > ref3# grep ksevar.h kern/*
> > kern/kern_switch.c:#include <sys/ksevar.h>
> > kern/kern_thread.c:#include <sys/ksevar.h>
> > kern/sched_4bsd.c:#include <sys/ksevar.h>
> > kern/sched_4bsd_kse.c:#include <sys/ksevar.h>
> > (note that kern_thr.c is not one of them)
> >
> > My plan is:
> > eventually, sched_4bsd.c will only do the original BSD
> > scheduling (except with threads instead of procsses)
> > i.e. unfair, but simple and easy to benchmark on non-threaded apps.
> > (or on threaded apps with no competing processes)
> >
> > sched_4bsd_kse.c will suck in the current contents of kern_switch.c
> > and the KSE'd version of sched_4bsd.c.
> >
> > this will act like the current 4bsd scheduler WITH KSEs
> >
> 
> There is a better way to do this.  If you would listen to my tiered
> approach you could end up with one copy of sched_4bsd and not two.
>  The kse specific logic could just sit in kern_kse which would not
> tell sched_4bsd about threads until they owned the KSE.  We could
> even do this without the kse structure as a go between.

I think that is an overcomplication.
the two BSD based files would be very different.
For a start the simple one would be queueing threads on the run queues.
A system compiled with that scheduelr would have no KSEs anywhere
in the entire kernel.
The kse one would be queueing KSEs. I don't see how you can do this
with a shared file.

Anyhow, the following hack (totaly unoptimised.... notice the 
existance of sched_td_exit, sched_exit_thread, and sched_thr_exit..
I just haven't got to cleaning it) is not so advanced that
the question of tiered schedulers is relevant yet..
this patch just shows that it is possible to get the KSEs
out of the rst of the system.

> 
> > switch.c will go away (unless you want it as part of ULE).
> >
> > kern_thread.c will forget all about KSEs
> > (but its not there yet).
> >
> > I'll send the patches in an hour or so..
> > My wife's calling :-/
> >
> >
> >
> >
> >
> >
> > >
> > > >
> > > > Julian
> > > >
> > > >
> > >
> > >
> >
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hack.tgz
Type: application/octet-stream
Size: 51200 bytes
Desc: 
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20030416/83c664e1/hack-0001.obj