From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 21:54:10 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 308A616A4E2 for ; Fri, 27 Oct 2006 21:54:10 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 951CB43DD6 for ; Fri, 27 Oct 2006 21:53:28 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 751DF5B5A; Fri, 27 Oct 2006 14:53:14 -0700 (PDT) To: Julian Elischer In-reply-to: Your message of "Fri, 27 Oct 2006 12:27:14 PDT." <45425D92.8060205@elischer.org> Date: Fri, 27 Oct 2006 14:53:14 -0700 From: Bakul Shah Message-Id: <20061027215314.751DF5B5A@mail.bitblocks.com> 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 21:54:10 -0000 > 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. The default may be to give each process the same share but in general one would want even more control over scheduling. For instance I may want one group of processes to get 10% share (it may be encoding/serving a video stream in real time) and the remaining shared by everyone else. You need waited fair queuing or some such. This can allow one to structure an application in a natural way without having to worry about how scheduling will be impacted by a choice of threads vs processes. Have you guys looked at any networking related papers on scheduling? I see a lot of similarities in the goals and some algorithms may be useful. One can think of a tcp stream or traffic between two endpoints as equivalent of a thread. May be by throwing out all of KSE and simplifying the scheduler you/we have an opportunity to apply the lessons learned and come up with a leaner, more efficient and flexible design. The default scheduler can be dirt simple but easy to replace or enhance, may be with a loadble module, so that one can experiment with different algorithms without having to take the system down as well as punt to a user process for more complex decisions. This is assuming a very simple plugin API is possible (definitely not a given). FWIW. -- bakul