From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 20:18:39 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 BD4CF16A403 for ; Fri, 27 Oct 2006 20:18:39 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from riyal.ugcs.caltech.edu (riyal.ugcs.caltech.edu [131.215.176.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C1BF43D73 for ; Fri, 27 Oct 2006 20:18:39 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by riyal.ugcs.caltech.edu (Postfix, from userid 3640) id 2A2BB45806; Fri, 27 Oct 2006 13:18:38 -0700 (PDT) Date: Fri, 27 Oct 2006 13:18:38 -0700 From: Paul Allen To: Julian Elischer Message-ID: <20061027201838.GH30707@riyal.ugcs.caltech.edu> References: <45425D92.8060205@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45425D92.8060205@elischer.org> Sender: jd@ugcs.caltech.edu Cc: 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 20:18:39 -0000 >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. First the name-calling: What you're talking about is communist scheduling. It insists that I the user should conform to the scheduler's notion of the right ratio of processses to threads. Now the serious response: By fair-scheduling what you mean is recreating through quite a bit of computation some of the scheduling defects of libc_r: namely that threading is denied the same concurrency granted to multi-process based architectures. I now rather instantly apprehend why multi-threading has lagged behind so much on FreeBSD. Let me tell you right now, this is not an assumption people consider when multithreading their applications. Can you offer an explanation as to why the scheduler should care about the balance of active users/active threads/active processes? If you desire partitioning there is a simple answer: rlimits covering the number of threads, processes, threads per process, etc. And hint: almost everyone will turn these limits off. The only necessary fairness property is between threads. The scheduler cannot ascertain among several threads which are doing important work merely by virtue of how they are distributed among the vmspaces (processes). This sort of distinction should be left under the control of process priority, thread priority, and rlimits. Paul