lkwt in DragonFly

[Julian Elischer]

Jeroen Ruigrok/asmodai wrote:




N:1 threads :.....

- all threads within a single process compete for a portion of the
  timequanta allocated to process A, nicing a thread will only make it
  consume more of the quanta allocated to process A and doesn't let it
  compete for more CPU with other processes unless you nice process A in
  its entirety (so no 'real-time' threads)
This is where FreeBSD threads diverges from SAs
FreeBSD has a separate structure, called a Ksegroup.
KSEgroups atr the container for all characteristics that a non threaded
process considers to be per-process scheduler characteristices.
these include:
things like "nice".  The Nice value is acssociated with the KSEG.
 threads in another KSEG are not affected.. By default threads ARE in the 
same KSEG.

KSEGs provide a convenient handle by which 'fairness' function scan be added 
to teh scheduler.. For example a KSEG has its own run queue where (kernel) 
runnable threads are hung. this allows the kernel scheduler to
treat those threads as having less 'weight' than teh same number of 
processes. 9i.e. a process with 100 threads , when running against a single 
threaded program should not get 100/101 of the cpu.

Note: Fairness has not been completely implemented but there is a crude 
fairness algorythm in teh FreeBSD scheduler.. in fact it's too fair..
threaded apps get a bit penalised I think.. it needs work, but
the ability to group the kernel threads into these groups
(whether 1:1 or M:N, it doesn't matter) is a significant departure
from the normal threading system and give the FreeBSD threading system a 
flexibility that is pretty much unrivalled..


- no advantage of multiple CPU loading

two-level scheduler pthreads implementation (M:N):

user threads are mapped to kernel threads taken from a pool of kernel
threads, there is no relationship between the threads, in fact it can be
reallocated to another (free) kernel thread in future
This can make resource tracking a bit harder, and debugging too, but we are 
solving those problems.. for resources, it is often possible for us to 
assign those resources to a KSEG instead of the thread.
The KSEG, unlike the kernel thread, is usually permanently associated with a 
thread, (or, rather a user thread is not usiall migrated to a differnt KSEG)
and resources tracked per group of threads often makes more sense anyhow
when threads can be ephemeral.



you can dump threads that often wait on I/O, sleep on timers, are events
inside one kernel thread
for CPU heavy threads you can assign a 1:1 mapping to take advantage of
loading the CPUs with threads that will keep them busy (Digital Unix
actually detected changes in a thread's behaviour)
KSE can run in either mode. it's both compilable AND a runtime option.


not all threads within a single process are bound to the process'
execution context, thereby allowing threads to spawn multiple CPUs
The internal complexity is the only thing against it.

The complexity is only 30% over that you need to add to implement 1:1 
threads anyhow. Most of the changes required apply to both systems..