Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 05 Jul 2006 13:20:49 +0800
From:      David Xu <davidxu@freebsd.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        Daniel Eischen <deischen@freebsd.org>, Robert Watson <rwatson@freebsd.org>, freebsd-threads@freebsd.org
Subject:   Re: Strawman proposal: making libthr default thread implementation?
Message-ID:  <44AB4C31.5090402@freebsd.org>
In-Reply-To: <44AB46CF.9030503@elischer.org>
References:  <20060703101554.Q26325@fledge.watson.org> <44AAC47F.2040508@elischer.org> <200607050706.33502.davidxu@freebsd.org> <200607050724.18740.davidxu@freebsd.org> <44AB46CF.9030503@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44AB4C31.5090402>