From owner-freebsd-threads@FreeBSD.ORG Wed Jul 5 05:20:49 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0052F16A4E1; Wed, 5 Jul 2006 05:20:47 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <44AB4C31.5090402@freebsd.org> Date: Wed, 05 Jul 2006 13:20:49 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060519 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <20060703101554.Q26325@fledge.watson.org> <44AAC47F.2040508@elischer.org> <200607050706.33502.davidxu@freebsd.org> <200607050724.18740.davidxu@freebsd.org> <44AB46CF.9030503@elischer.org> In-Reply-To: <44AB46CF.9030503@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Robert Watson , freebsd-threads@freebsd.org Subject: Re: Strawman proposal: making libthr default thread implementation? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2006 05:20:49 -0000 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.