From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 21:06:24 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 02C0116A40F for ; Fri, 27 Oct 2006 21:06:24 +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 8299D43D7B for ; Fri, 27 Oct 2006 21:06: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 k9RL6Aoo005964; Fri, 27 Oct 2006 17:06:10 -0400 (EDT) Date: Fri, 27 Oct 2006 17:06:10 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Matthew Dillon In-Reply-To: <200610272050.k9RKoXo3045280@apollo.backplane.com> Message-ID: References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <200610272050.k9RKoXo3045280@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]); Fri, 27 Oct 2006 17:06:10 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Paul Allen , 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 21:06:24 -0000 On Fri, 27 Oct 2006, Matthew Dillon wrote: > > :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 > > This is a nice concept, but totally unrealistic in actual operation > because you generally have no control over how the application > programmer designed his application. It is the user running the > application who needs to be able to control how the thread scope > effects the overall system, not the application designer. > > The argument here is not how a program runs alone on a system, but how > it effects the performance of other programs running on the system. > > Unless you are advocating that the system administrator or user perform > surgery on every single application in the system (KDE, Firefox, and > on down the line), the problem cannot be solved by depending on > programmers to do the right thing vis-a-vie the POSIX standard. Two things. You kernel shouldn't be designed to make it impossible to support POSIX operations and behavior. There are various ways that you can force a threads library or kernel to use system or process scope threads. We do it now with environment variables in libpthread, or as a compile option when building libpthread. You could also have a sysctl that forces threads to be created one way or another. Users can, if they are unhappy with the performance of the threaded application, force it to use one or the other scheme, within limits as set by the administrator. -- DE