Re: kthreads->kproc and back to kthread.. next patch

Julian Elischer wrote:
> Here is the link to the next patch.
> 
> this introduces (back) the kthread_create (etc) calls but now they
> make threads..
> It's still in the testing stage..
> I'd certainly appreciate feedback.
> Especially as some of the locking and stuff has changed since I first 
> wrote this and tested it over 2 years ago.
> 
> One possibility.. changing kthread_create() to kthread_new()
> so that any people who are using the old kthread_create() don't get the new
> one by mistake....
> 
> 
> after this is committed, I will start changing over some of the callers 
> of kproc_create,
> one at a time....
> 
> 
>     http://people.freebsd.org/~julian/kthread.diff
> 
> 
> it may also be worth adding some help for people to make a new kproc,
> and populate it with a number of kthreads.
> 
> for instance it would be aesthetically pleasing to have a single idle 
> process,
> and have all the idle threads be part of that single process.
> 
> Similarly, might things like the syncer or other processes ever benefit 
> from having multiple threads?
> Anyhow that's another discussion.

Why is there a need for separate kprocs with their own private kthreads
in the kernel?  The kernel is a single unified address space; I thought
that the only real benefit to "true" kthreads was just elimination of
duplication of vmspaces for all off the kthreads that are currently
running around.  Do I gain some sort of security or management benefit
from having my own private kproc for my kthreads, or am I really just
burning another vmspace object and nothing more?  What about the
existing fast context switching between kthreads (i.e. not flushing CR3
on the switch), will that remain, or does it now get more complicated?
Are there scheduling implications and benefits?  In fact for that
matter, how is scheduling going to be done for this?  Is it all going to
be 1:1 style scheduling, or will there be a multi-tier scheduler for
kprocs and kthreads and associated niceness/fairness?  What about high
priority kthreads like ithreads, taskqueues, and SWI's?

If I've missed the discussion on scheduling, I apologize.  If not, have
these questions been thought through yet?

Scott