From owner-freebsd-current@FreeBSD.ORG Thu Jan 4 23:49:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1F71316A403; Thu, 4 Jan 2007 23:49:55 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: "Kip Macy" Date: Fri, 5 Jan 2007 07:49:48 +0800 User-Agent: KMail/1.8.2 References: <20070104005625.D1508@10.0.0.1> <459CCBA1.40305@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701050749.49058.davidxu@freebsd.org> Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE 2.0 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: Thu, 04 Jan 2007 23:49:55 -0000 On Friday 05 January 2007 03:31, Kip Macy wrote: > 4BSD is robust, but I wouldn't say it scales well. The way its decay > scheduling is implemented is very centered around having one queue. The > algorithm also does not have any way of taking more complex topologies > multi-package vs. multi-core vs. multi-thread into account. The scheduler > isn't FreeBSD's biggest scaling problem, but it will definitely wear thin > with time. > > > -Kip I am not sure 4BSD was designed for single queue, I only know it is just a dynamic priority alogrithm for time-sharing process. Within large system, you may have to split resource into some regions and hierarchies, each region will have a load average, (current we only have single load average), thread may always have affinity with region resources, the region may have a global run queue which for example is designed for real-time thread or kernel thread which should be run as soon as possible, user or less important thread can be on per-cpu queue. Current, the problem in ULE and Linux scheduler is they don't care priority balance, a CPU may have many high priority threads while another CPU may only have few of them, while all alogrithm are designed based on priority scheduling, this problem can not be ignored, I have a two CPUs priority balance algorithm based on Solaris idea,the algorithm is also cache-affinity, I must say it have best performance when running mysql super-smack, normally I can 8% better performance on 2-cpu system, it is still 4BSD, I don't have algorithm for 4 cpu or more yet. since we use blockable mutex and priority propagation, I think priority is important, if spinlock is widely used, each spinlock looks like a critical region, then priority is less important, Linux widely uses spinlock, it might be only of reason why it still works. Regards, David Xu