Strawman proposal: making libthr default thread implementation?

[Julian Elischer]

David Xu wrote:

> Julian Elischer wrote:
>
>> 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.
>>
>
> but it still has bias to M:N, the kg_user_pri member which is not right
> for 1:1 thread, this also makes user interaction detection algorithm
> impossible, e.g one thread is cpu-bound while another thread is
> user-interaction thread, this model will make it impossible,
> and two threads will be treated as cpu-bound, the concurrency limit
> in ksegrp(4bsd/ule scheduler) also makes cpu-affinity algorithm to
> be more diffcult, as kern_switch.c will withdraw a thread from
> scheduler runqueue by a very simple reason - concurrency level.


well then have  a separate KSEG for each thread..

>
>> 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.
>>
>
> I would like to see a top level long term scheduler to adjust
> decay factor as Solaris did, this would make fairness better than
> ksegrp, ksegrp mechanism still can only manage a process but has
> above issues.


if you have a single KSEG for each thread, then you are welcome to have 
another method of producing thread fairness.
if it can be shown to work then we can make ithte default way to run.. 
As I said, I did this work kbecause FreeBSD
NEEDED threads and no-one was doing it, but I am pretty agnostic on how 
they should be implemented for the acerage thread user.