Strawman proposal: making libthr default thread implementation?

[Julian Elischer]

David Xu wrote:

>On Wednesday 05 July 2006 07:06, David Xu wrote:
>
>  
>
>>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...
>>    
>>
>
>OK, I just digged out the paper in my disks,  here is the reference:
>http://people.freebsd.org/~davidxu/doc/solaris2.pdf
>
>[the address thread at freebsd.org is removed]
>
>I think we really should do more work in kernel scheduler, and remove
>ksegrp.
>  
>

the original aim for the ksegrp was not for fair scheduling but to allow 
libraries to instanciate
their own threads in a way that they did not impact the application's 
threads in any way.
Effectively, running them in their own process.. Fair scheduling just 
made use of it as a convenient
abstraction.
Removing the ksegrp entirely just reduces everything down to being 
boring threads with no possibility of
ever doing anything different.

KSEs have already gone, except as a scheduler abstraction.
and having KSEGROUPs shouldn't affect anything negatively from no on.
though they could be renamed threadgroups now.

The scheduler complexities we see now do not come from having ksegrps, 
but rather, from trying to
do fair scheduling in the rather simplistic "obvious" manner that I 
did.  I am truely
surprised that someone has not come up with a better way to do it by 
now. I was expecting that
the current approach would have been replaced by something more 
sophisticated by now.



>David Xu
>  
>