Date: Thu, 27 Sep 2001 22:54:59 -0700 From: Julian Elischer <julian@elischer.org> To: arch@freebsd.org Subject: KSE next steps... Message-ID: <3BB410B3.A2527C09@elischer.org>
next in thread | raw e-mail | index | archive | help
Well things seem to have setled down with -current and KSE part 2.
so I guess it's time to start looking at the next steps.
Here are some topics I'd like to look at:
1/ allocation schemes for threads/kses/ksegrps
These need to be independently allocatable..
There are some questions however..
Should they be allocated from a zone allocator similar to that
currently used for process structures?
Should the vm object associated with threads structures be allocated
and 'left' as it presently is (type stable storage)?
Should the thread structure that comes with the proc structure be used as one of
the
threads for KSE operation, or should it be left untouched until
KSE mode is stopped (or exit)? If we use the thread pre-packed with the proc
there are some problems..
For example: it is intimatly associated with one process, but thread structs in
KSE
mode are transient, and might be given to a different process should it be
needed
there. (kernel thread structures are only 'used' when the thread enters the
kernel
due to a trap of some sort (e.g. syscall) until it returns back to user land).
It provides the stack and storage for the thread to transfer from user to kernel
and is 'empty' while the thread is running in user space.
Another option might be to ALWAYS allocate them separatly.. That makes the first
one
just another thread struct... but it may be more 'expensive' to allocate tehm
that way.
(though thay could be cached...)
2/ When processes have a single state, (e.g. SLEEP, RUN etc.) it becomes
possible
for a process to simultaneously have threads in multiple states.. What do we do
in all the places that current code assumes a single monolithic state,
and how do we report the stat of such a process in /proc or ps?
- My guess is that a single state 'KSE' for a process should indicate that no
finer
state information is available for that process until we add code to 'ps' to
support it.. We can alter ps and friends to simply give up if they see that
state..
3/ similar for reporting wmesg information..
4/ What does a process with 4 threads do if you send it a SIGTSTP and it has a
number of threads (maybe on a different processor) presently suspended in
syscalls
or, maybe running in syscalls.
(other questions later when I think of them..)
The next steps:
a) add allocators/destructors for threads, kses and ksegrps
b) use them, and add code to fork() (and friends) to use them
c) define the user interface so that uerland code can start to be planned.
(I may just do that first.)
d) add the syscalls to switch modes etc.
e) make a single test syscall that exercises some of this...(no locking.. just
simple)
julian
--
+------------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ julian@elischer.org +------>x USA \ a very strange
| ( OZ ) \___ ___ | country !
+- X_.---._/ presently in San Francisco \_/ \\
v
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?3BB410B3.A2527C09>