From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 22:37:31 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 7155116A4AB for ; Fri, 27 Oct 2006 22:37:31 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAE3443D49 for ; Fri, 27 Oct 2006 22:37:17 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 15:37:17 -0700 Message-ID: <45428A1C.3020902@elischer.org> Date: Fri, 27 Oct 2006 15:37:16 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Matthew Dillon References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <200610272044.k9RKijTe045236@apollo.backplane.com> In-Reply-To: <200610272044.k9RKijTe045236@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Allen , 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: Fri, 27 Oct 2006 22:37:31 -0000 Matthew Dillon wrote: > I think the real issue here is that it is fairly difficult... probably > close to impossible in fact, to write a general purpose scheduler in > the kernel that can handle the types of extreme cases that can occur > when the kernel is made responsible for managing a user program's threads. > > A better approach would be to make the kernel responsible for scheduling > cpu slots for programs, a far more manageable number, and if a program > wants to have thousands of threads on a 4-cpu system it (i.e. libthr) > should then have the responsibility of telling the kernel which > threads to pop into those slots at any given moment. hey, wait, that's what the M:N library does! > > So, for example, if a machine has 4 cpus the kernel has 4 scheduling > slots it can fill. The kernel can apportion those slots with its current > scheduler technology. But if there is a program running on the system > that has thousands of threads, then why in the world would you want to > try to make the kernel scheduler deal with all those threads at once > when it only has 4 cpus to assign them to anyhow? So what you would > have instead would be the kernel saying to the program 'ok, I have 3 > slots available for you at the moment' and make the program responsible > for telling the kernel which threads to run in those 3 slots. And > then a little while later the kernel might say 'I have 4 slots now', > or 'now I only have 2 slots available', etc etc. > > This would then be a far more solvable problem for the kernel scheduler. > > If you as the user then want the kernel to give the program with > thousands of threads more of the available cpu, it simply becomes a > matter of running the program at a lower NICE value. > > -Matt