From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 12:08:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E65A016A40F for ; Sat, 28 Oct 2006 12:08:52 +0000 (UTC) (envelope-from thomas.sparrevohn@btinternet.com) Received: from smtp802.mail.ird.yahoo.com (smtp802.mail.ird.yahoo.com [217.146.188.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 5461A43D53 for ; Sat, 28 Oct 2006 12:08:51 +0000 (GMT) (envelope-from thomas.sparrevohn@btinternet.com) Received: (qmail 53005 invoked from network); 28 Oct 2006 12:08:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:In-Reply-To:References:Mime-Version:Content-Type:Message-Id:Cc:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=q9iDNoK+kQF6LO84OtF54OCd0QKWS4wrmMjbeSachW35nRNhBCSHxn/dveq1ExRk5YlqJdFHeahBaPRaQe5VG4PQOR3++iEQaZQ+XdTKGTu3397wJbkdiBhPDCWRcWJl3LmZj6jn1PEeW6nw4G+sA6XmOxqu/fUYKwR7hz1Y1D0= ; Received: from unknown (HELO ?192.168.0.15?) (thomas.sparrevohn@btinternet.com@86.136.31.56 with plain) by smtp802.mail.ird.yahoo.com with SMTP; 28 Oct 2006 12:08:49 -0000 In-Reply-To: <20061028105454.S69980@fledge.watson.org> References: <45425D92.8060205@elischer.org> <200610281132.21466.davidxu@freebsd.org> <20061028105454.S69980@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <614921E1-9243-48BF-BB8D-BFECB5EAAD78@btinternet.com> Content-Transfer-Encoding: 7bit From: Thomas Sparrevohn Date: Sat, 28 Oct 2006 13:08:47 +0100 To: Robert Watson X-Mailer: Apple Mail (2.752.2) Cc: freebsd-current@freebsd.org, David Xu , Julian Elischer Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 12:08:53 -0000 On 28 Oct 2006, at 11:04, Robert Watson wrote: > > On Sat, 28 Oct 2006, David Xu wrote: > >> 3) Third, it adds overhead to scheduler (I have already post a >> number) and might make locking more diffcult for per-cpu queue >> like scheduler, since now you always have to contend the ksegrp >> runqueue lock between many CPUs, also because you have build the >> fairness in the scheduler and every scheduler must obey the ksegrp >> algorithm, it may make more diffcult to implement another >> alogrithm and replace it, see 4). > > This is my single biggest concern: our scheduling, thread/process, > and context management paths in the kernel are currently extremely > complex. This has a number of impacts: it makes it extremely hard > to read and understand, it adds significant overhead, and it makes > it quite hard to modify and optimize for increasing numbers of > processors. We need to be planning on a world of 128 hardware > threads/machine on commodity server hardware in the immediate > future, which means that the current "giant sched_lock" cannot > continue much longer. Kip's prototypes of breaking out sched_lock > as part of the sun4v work have been able to benefit significantly > from the reduced complexity of a KSE-free kernel, and it's fairly > clear that the task of improving schedule scalability is > dramatically simpler when the kernel model for threading is more > simple. Regardless of where the specific NO_KSE option in the > kernel goes, reducing kernel scheduler/etc complexity should be a > first order of business, because effective SMP work really depends > on that happening. > I would add another concern - While I understand why fairness are useful in resource allocation - I do not think it makes sense unless the principle are use against all limited resources and hence in order for it to make sense it would mean a major rework of all allocation structures in the kernel. After all what is the use of getting CPU time of all file descriptors are used by another process etc. etc. In short the "fairness" proposed only a partial guarantee not a truly useful end-user situation.