Date: Mon, 7 Jan 2002 01:42:25 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: arch@freebsd.org Subject: KSE status Message-ID: <Pine.BSF.4.21.0201070115440.40482-100000@InterJet.elischer.org>
next in thread | raw e-mail | index | archive | help
I have the KSE kernel past another milestone. basically the running states
of threads and processes have been completely rewritten. (this is not yet
milestone 3, but it's about 2 and 7/8).
Some of the following states are not neccesarily final...
Some represent states that I may never need..
Processes have the following states:
PRS_NEW = 0, /* In creation */
PRS_NORMAL, /* KSEs can be run */
PRS_STOPPING, /* received sigstop, may be running
threads*/
PRS_STOPPED, /* received sigstop, all threads stopped*/
PRS_WAIT, /* Waiting on interrupt ? */
PRS_EXITING, /* Shutting down */
PRS_ZOMBIE
KSEs have the following states:
KES_IDLE = 0x10,
KES_SUSPEND,
KES_ONRUNQ,
KES_RUNNING
threads have the following states:
TDS_MAKING = 0x20, /* should be TDS_NEW */
TDS_UNQUEUED, /* Only very temporary state */
TDS_SLP,
TDS_MTX,
TDS_SLP_MTX, /* stupid state that can happen */
TDS_RUNQ,
TDS_RUNNING,
TDS_IWAIT,
TDS_SURPLUS /* about to be discarded */
Note: as of this moment, KSEGROUPS have no states.
To understand these states you need to look at the diagrams
of process and thread run-queue manipulations
at http://www.freebsd.org/~julian/
Basically as many KSEs as are needed or avaliable are queued
on the system run queues. They are associated with a KSE group.
The KSE group has a run-queue associated with it.
the runnable threads are queued off this.
Threads are ALWAYS queued off the KSEGRP even when the process is in a
STOPPED or SUSPENDED state. In this case the KSEs are not queued to the
system, but the thread housekeeping still queues the threads to the
KSEGRP exactly as it would if the process were runnable.
As KSEs run they reap threads off the KSEGRP run queues and complete them.
Basically this means that multiple threads can be run under the auspices
of a single process, possibly under multiple processors.
Basically I have this scheme emululating the current system, as long as
there are never more than 1 thread per process.
I have seen compiles and "make buildworld" pretty much succeed.
I have problems still with signals, particularly STOP and CONT
but I think I'm close to making the system, reliable for NON SMP systems
The code (from the site above or the CVSUP addresses quoted last week)
is now in a state where readers should be able to get a rough
idea of where I'm going. It's still very rough but it's in a state where
it requires more eyes and more fingers.
During the next two weeks My wife is expecting our first child (fingers
crossed) so I have not been able to spend as much time as I'd like to on
this, and I may become severely time constrained over the next few months,
but if I can get others to start helping here I can certainly code a bit
and guide.
Things that need to be done include just reading the code and trying to
think of better ways of doing some of the things I've done.
We also need a 'signals' expert to check that signals in the 1:1 case
still act the same (through code inspection).
I also need to have the userland syscalls added to allow the creation of
more than one thread per process. basically this is the code to turn on
the "async syscalls" mode of operation. I have written a lot of the kernel
support code but just need some syscall entry points to tie it into.
(/sys/sys/kse.h documents the syscalls at the moment with more coming)
I believe there is someone looking at that (right glenn?)
Anyhow I think that the code is now in a state where others can start
playing with it so I'd love to start seeing soem comments and patches.
Julian
P.S. it's a Girl
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0201070115440.40482-100000>