From owner-freebsd-hackers Mon Oct 1 21: 4:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta10.onebox.com (mta10.onebox.com [64.68.76.184]) by hub.freebsd.org (Postfix) with ESMTP id 2E4AE37B40E for ; Mon, 1 Oct 2001 21:03:53 -0700 (PDT) Received: from onebox.com ([10.1.101.5]) by mta04.onebox.com (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20010930195319.PQDX19615.mta04.onebox.com@onebox.com>; Sun, 30 Sep 2001 12:53:19 -0700 Received: from [66.32.1.193] by onebox.com with HTTP; Sun, 30 Sep 2001 12:53:19 -0700 Date: Sun, 30 Sep 2001 12:53:19 -0700 Subject: Re: KSE next steps... From: "Glenn Gombert" To: Julian Elischer Cc: hackers@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20010930195319.PQDX19615.mta04.onebox.com@onebox.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A couple of questions come to mind after reading what has been done so far and what ( think has been committed into the the Free BSD Current tree)and reading throught the present KSE write up.. How much of the KSE code is dependant upon the SMP support being fully functional?? The new system call(s) sa_new(cpy_id), sa_pressmpt)...etc seem to depend upon the new SMP support being functional in the 'Current' tree...is this the case or call's like "sa_new(cpu_id) will just create one KSE per avaiable CPU (one on a single cpu machine).. > 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...) Are all of the API's in section 3.3 of the KSE white paper implemeted with SMP support (like thread_new(), thread_preempt()... etc ?? > 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.. > Has the Kenrnel Scheduler been changed to support the creation of KSE's or is that planned fir this next phase ?.. > 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.. What sort of mechanism has been used todate to test the functionality that has been added to the kernel code in the 'Current' branch so far?? I am just coming up to speed on some of this and have been waiding through the way the 4.x kernel functions now and how it is envisioned to function under 5.0.... > 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 > __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message