From owner-freebsd-current@FreeBSD.ORG Sun Oct 29 04:53:19 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 6BF6916A412; Sun, 29 Oct 2006 04:53:19 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE19043D46; Sun, 29 Oct 2006 04:53:18 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k9T4r8dm028809; Sun, 29 Oct 2006 00:53:08 -0400 (EDT) Date: Sun, 29 Oct 2006 00:53:08 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Matthew Dillon In-Reply-To: <200610290344.k9T3itAw054920@apollo.backplane.com> Message-ID: References: <45425D92.8060205@elischer.org> <200610281132.21466.davidxu@freebsd.org> <20061028105454.S69980@fledge.watson.org> <20061028194125.GL30707@riyal.ugcs.caltech.edu> <20061028204357.A83519@fledge.watson.org> <200610290344.k9T3itAw054920@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Sun, 29 Oct 2006 00:53:09 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Paul Allen , Robert Watson , Julian Elischer , freebsd-current@freebsd.org, David Xu Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2006 04:53:19 -0000 On Sat, 28 Oct 2006, Matthew Dillon wrote: > > (2) Just because the POSIX scheduler implements all sorts of different > scopes and priority schemes says NOTHING AT ALL about how programs > operating under such a scheduler should be apportioned cpu relative > to OTHER PROGRAMS WHICH ARE INDEPENDANTLY RUNNING ON THE SYSTEM. POSIX > is an abstraction (or virtualization out of available resources), > just like everything else. If you try to treat it as a hard requirement > the only result will be a broken system that might happily run everything > else into the ground and stop allowing root ssh logins in order to > accomodate a badly written POSIX program. There are many third party > applications that set POSIX priorities, in particular realtime > priorities, that I'd rather they not actually use. Most of these > programs set these priorities based on the author's attempt to tune > them on a single operating system (e.g. linux) and in a single operating > environment. > > All a program can ever really do when requesting POSIX scheduling > resources is compete against itself. It is the system operator, at a > higher level, that must control how those resources compete with > other programs. That should be clear to everyone it is so obvious. Actually, that's not quite true. I assume you know the thing you left out: system scope threads compete against all the other system scope threads in the system (from all applications, not just within one application). -- DE