cvs commit: src/sys/ddb db_ps.c src/sys/i386/i386 genassym.c kern_thread.c sched_4bsd.c sched_ule.c subr_smp.c subr_witness.c src/sys/sys proc.h

[Julian Elischer]

On Thu, 10 Apr 2003, John Baldwin wrote:

> 
> On 10-Apr-2003 Julian Elischer wrote:
> > julian      2003/04/10 10:35:45 PDT
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     sys/ddb              db_ps.c 
> >     sys/i386/i386        genassym.c 
> >     sys/kern             init_main.c kern_fork.c kern_mutex.c 
> >                          kern_proc.c kern_thread.c sched_4bsd.c 
> >                          sched_ule.c subr_smp.c subr_witness.c 
> >     sys/sys              proc.h 
> >   Log:
> >   Move the _oncpu entry from the KSE to the thread.
> >   The entry in the KSE still exists but it's purpose will change a bit
> >   when we add the ability to lock a KSE to a cpu.
> 
> Why not add a ke_pincpu to hold the bound CPU?  Since KSE's are in
> theory a kind of virtual CPU abstraction the thread really seems to
> be the wrong place for this information.

That's what I said (or at least meant to)(except that I haven't renamed
the old entry in the ke yet (I haven't decided on a name)).

The entry in the thread only says where it is running NOW.
All of the users of the "what cpu are you on now?" value
can use it better if it's in the thread. In many cases this was the only
reason for the code in question to even know that there was such a thing
as a KSE, where they already have a thread pointer.

This is part of my push to make the KSE itself invisible to parts of the
CPU that don't need toknow about it..

Much of the kernel needs to know only about threads. 
A slightly smaller but largely different part needs to know about
processes.
A much smaller part needs to know about KSEGRPS,
Almost nothing outside the scheduler needs to know about KSEs.

Since KSEs themselves are really a scheduler abstraction (i.e. a
fairness tool mostly) since David created the upcall structure, I'm
trying to limit their use to within the scheduler. This gives us a
possibility of creating a thread scheduler that uses a completely
different way of enforcing fairness, and in fact my first test of
whether I have succeeded will be to create an "unfair" scheduler, that
has no KSEs and schedules the threads directly.

It's un unfortunate fact that when we allocated names to the various
structures on teh whiteboard in 1999 we called the entry that was put on
the run-queue to enforce fairness the KSE, and that name came to
symbolise the entire effort, because it's the structure most likely to
be found un-needed if someone writes a different thread scheduler.

 This leaves us in the odd situation of having "KSE" threading possibly
without KSEs. Unfortunatly the names have been "organically grown"
during discussions a couple of years ago and "stuck". I've been pushing
for a long time now about renaming things but discussion has always
ended up with "yes, but we've more important things to fix right now".
:-)

I might add that the upcall structure may end up being the main vehicle
for cpu binding rather than the KSE. Obviously the scheduler is involved
in that so the KSE may also be involved, as it's visible.

> 
> -- 
> 
> John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
>