Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Sep 2001 12:53:19 -0700
From:      "Glenn Gombert" <glenngombert@onebox.com>
To:        Julian Elischer <julian@elischer.org>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: KSE next steps...
Message-ID:  <20010930195319.PQDX19615.mta04.onebox.com@onebox.com>

next in thread | raw e-mail | index | archive | help

 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010930195319.PQDX19615.mta04.onebox.com>