From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 05:34:38 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 48B3216A412; Sat, 28 Oct 2006 05:34:38 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D851943D49; Sat, 28 Oct 2006 05:34:37 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k9S5YVJr018241; Sat, 28 Oct 2006 01:34:32 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200610281206.13588.davidxu@freebsd.org> References: <45425D92.8060205@elischer.org> <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542D3A8.1040500@elischer.org> <200610281206.13588.davidxu@freebsd.org> Date: Sat, 28 Oct 2006 01:34:30 -0400 To: David Xu , freebsd-current@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: Daniel Eischen , Julian Elischer , "Alexandre \"Sunny\" Kovalenko" 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 05:34:38 -0000 At 12:06 PM +0800 10/28/06, David Xu wrote: >On Saturday 28 October 2006 11:51, Julian Elischer wrote: > > Alexandre "Sunny" Kovalenko wrote: > > > > > > I apologize for misinterpreting your words. But then, if I have > > > M:N set to 10:1, I would expect application with 1000 process > > > scope threads to have as many CPU slots as 100 processes, or, > > > if I have 10 system scope threads and 990 process scope threads, > > > I would expect application to have as many CPU slots as 109 > > > processes. Is this what you refer to as "fairness"? > > > > M:N is not a ratio, but rather the notation to say that M user > > threads are enacted using N kernel schedulable entities (kernel > > threads). Usually N is limited to something like NCPU kernel > > schedulable entities running at a time. (not including sleeping > > threads waiting for IO) > > (NCPU is the number of CPUs). > > > > so in fact M:N is usually M user threads over over some number > > like 4 or 8 kernel threads (depending on #cpus) plus the number > > of threads waiting for IO. > > >> Julian > >As you are emphasizing fairness, I must say I don't believe fairness >in libpthread either, I don't think writting a fairness scheduler is >an easy work, does kernel have made fairness for threads in same >ksegrp, so does libpthread's userland scheduler ? they don't, it can >make threads in same ksegrp misbehaviored, so what we have done is >still process scheduling fairness even there is ksegrp in kernel, >and now sacrificed fairness between threads. I think we have different ideas of what is the goal is with this claim of "fairness". If I understand it right, it is *not* that some static code in the kernel is going to decide which applications are fair and which ones are not fair. IIIRC, what Julian wants to do is provide a way that the administrator can make that decision. The administrator will have a way to throttle some thread-crazy process, but only if the *administrator* wants to do that. If the machine is for a single user, then that user will probably set "N" to a high value. But if the machine has a lot of users on it, then the administrator of that machine may want to set "N" to the number of CPU's on the system, or maybe the number of CPU's minus 1. And if the users don't like that, then they can go buy their own damn machine instead of using the machine someone else bought and is allowing them to access for free. At RPI we have both kinds of machines. Machines owned by a single user, and machines which have multiple students ssh'ed into at the same time. I can see wanting to throttle thread-crazy processes on some machines, and not wanting any throttling at all on others. ...but it has been a few years since the presentation that I remember Julian giving about this, so maybe I am not remembering it correctly. I do remember that whatever it was, it sounded pretty reasonable at the time. :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu