DragonFly BSD
DragonFly kernel List (threaded) for 2004-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: lkwt in DragonFly

To: Jeroen Ruigrok/asmodai <asmodai@xxxxxx>
From: Julian Elischer <julian@xxxxxxxxxxxx>
Date: Wed, 11 Feb 2004 18:38:17 -0800

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

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]