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

Scott Long wrote:

a lot of questions: I'll separate them.

> 
> Why is there a need for separate kprocs with their own private kthreads
> in the kernel? 

Generally there is not. Hence this change.


> 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. 

yes, and the overhead that goes with it. i.e. double the number of 
processes on an average system -> extra contention on process related locks etc.



> 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? 


Except for the case of AIO, you are currently burning an extra proc 
structure for no reason. That's why I'm switching.. 
Realize that up until now all kernel threads have been full processes. 
What I'm doing is:

1/ changing the name of the exisitng function that makes processes to 
   a name that actually says that.

2/ introducing a new function that makes an actual kernel THREAD.
 
3/ switching as many possible of the users to use the THREAD version.


> 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?

It stays the same

> Are there scheduling implications and benefits
 
not really

>
> 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?

no change. All threads are individually scheduled as they are now.

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

yes

> 
> Scott