From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 01:15:16 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 E20FB16A403; Sat, 28 Oct 2006 01:15:16 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FEAC43D46; Sat, 28 Oct 2006 01:15:16 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([70.21.180.196]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J7T00B3UNH6FBB6@vms044.mailsrvcs.net>; Fri, 27 Oct 2006 20:15:07 -0500 (CDT) Date: Fri, 27 Oct 2006 21:15:04 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: To: Daniel Eischen Message-id: <1161998104.872.18.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> 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 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 01:15:17 -0000 On Fri, 2006-10-27 at 16:41 -0400, Daniel Eischen wrote: > 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). > I might be missing something here, but OP was separating M:N (which is what you are referring to above), and "fairness" (not giving process with 1000 *system scope* threads 1000 CPU scheduling slots). As far as I know the first one is POSIX and the second one is not. FWIW: as an application programmer who spent considerable amount of time lately trying to make heavily multithreaded application run most efficiently on 32-way machine, I would rather not have to deal with "fairness" -- M:N is bad enough. -- Alexandre "Sunny" Kovalenko