From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 20:41:21 2006 Return-Path: X-Original-To: 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 CF1FB16A40F for ; Fri, 27 Oct 2006 20:41:21 +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 658E043D5F for ; Fri, 27 Oct 2006 20:41:21 +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 k9RKfG9A012544; Fri, 27 Oct 2006 16:41:16 -0400 (EDT) Date: Fri, 27 Oct 2006 16:41:16 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Paul Allen In-Reply-To: <20061027201838.GH30707@riyal.ugcs.caltech.edu> Message-ID: References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> 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]); Fri, 27 Oct 2006 16:41:16 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Julian Elischer , current@freebsd.org 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: Fri, 27 Oct 2006 20:41:21 -0000 On Fri, 27 Oct 2006, Paul Allen wrote: >> From Julian Elischer , Fri, Oct 27, 2006 at 12:27:14PM -0700: >> The aim of the fair scheduling code is to ensure that if you, as a user, >> make a process that starts 1000 threads, and I as a user, make an >> unthreaded process, then I can still get to the CPU at somewhat similar >> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. > > Ah. Let me be one of the first to take a crack at attacking this idea as > a mistake. No, it is POSIX. You, the application, can write a program with system scope or process scope threads and get whatever you behavior you want, within rlimits of course. If you want unfair scheduling, then create your threads with system scope contention, otherwise use process scope. The kernel should be designed to allow both, and have adjustable limits in place for (at least) system scope threads. Noone is saying that you can't have as many system scope threads as you want (and as allowed by limits), just that you must also be able to have process scope threads (with probably higher limits or possibly no limits). -- DE