Strawman proposal: making libthr default thread implementation?

David Xu davidxu at freebsd.org
Tue Jul 4 23:06:57 UTC 2006


On Wednesday 05 July 2006 03:41, Julian Elischer wrote:
> As much as it pains me to say it, we could do with looking at using the
> simpler mode of 1:1
> as the default. M:N does work but it turns out that many of the
> promissed advantages turn out to be
> phantoms due to the complexities of actually implementing it.  The main
> problem that occurs
> again and again is that the kernel has no history of how a particular
> thread ran, which is important
> for our scheduer, and that there are other places where it would be
> advantageous for the kernel
> to have visibility into the whole pool of threads.  There is actually an
> answer for the 1st problem that
> I have played with but there continue to be complexities introduced that
> make it difficult. For example,
> keeping statistics alligned woth threads and reporting them for the
> correct thread is exteremely difficult.
>
This painful and complexies thing really should be avoided, the two
level scheduler will always lose some cached information.

> THIS MUST NOT be confused with the complexities introduced by trying to
> make threads run fairly.
> Some of the percieved advantages of going to 1:1 are in fact only
> achievable if we abandon fair
> scheduling, which is a completely orthogonal issue.
>
>
> The complexity that introduce the extra locking in the schedular that
> Kip refers to,
> is the attempt to do fair scheduling and is independent of 1:1 or M:N.
> If someone could work out  a way that fair scheduling could be achieved
> without
> the extra locking then that would be valid for both M:N and 1:1 THREADING,
> and would solve Kip's problem.
>
Cann't solaris's user usage scheduler will solve the problem ? if I 
recall it correctly, the decay factor in 4bsd scheduler can be changed 
dynamically for a thread, the decay factor can be stored in thread structure, 
and timeslice can be dynamically changed, also can be in thread structure,
unlike current implementation, timeslice is fixed,  this may make fair 
scheduling  possible without ksegrp.

Also will the roundrobin callout preempt a thread ?  if that's true, then
when every timeslice tick, a thread exhausted its timeslice is put at head
of runqueue, isn't it a bug ? the callout is somewhat random for a thread,
might not be a problem...

David Xu


More information about the freebsd-threads mailing list