Date: Sun, 30 Sep 2001 17:00:36 -0700 From: Julian Elischer <julian@elischer.org> To: Glenn Gombert <glenngombert@onebox.com> Cc: hackers@FreeBSD.ORG Subject: Re: KSE next steps... Message-ID: <3BB7B224.FF428740@elischer.org> References: <20010930195319.PQDX19615.mta04.onebox.com@onebox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Glenn Gombert wrote: > > 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).. A single CPU machine will hav only one KSE (per kseg) but it will still have completely asynchronous syscalls, so it will still be able to schedule many threads at once without the fear that one will block and block all the others.. So it's still very useful for UP machines. > > > > 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 ?? they (or similar ones) will be. We're still working out the API. > > > 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 ?.. that will be 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?? SO far the main aim was "No new functionality, and keep working" :-) > > 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.... did you look at the 5.0 kernel? > > > 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 -- +------------------------------------+ ______ _ __ | __--_|\ 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BB7B224.FF428740>