Patches for threads/scheduler abstraction.

Jeff Roberson jroberson at chesapeake.net
Wed Apr 16 19:18:22 PDT 2003


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.

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



More information about the freebsd-threads mailing list