From owner-freebsd-arch Thu Sep 27 23: 4:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 8C65C37B411 for ; Thu, 27 Sep 2001 23:04:10 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA68934 for ; Thu, 27 Sep 2001 23:51:18 -0700 (PDT) Message-ID: <3BB410B3.A2527C09@elischer.org> Date: Thu, 27 Sep 2001 22:54:59 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@freebsd.org Subject: KSE next steps... Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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