From owner-freebsd-arch Wed Jan 22 22:38:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDD6637B401 for ; Wed, 22 Jan 2003 22:38:45 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DCA743EB2 for ; Wed, 22 Jan 2003 22:38:45 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0N6cij70706 for ; Thu, 23 Jan 2003 01:38:44 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 23 Jan 2003 01:38:44 -0500 (EST) From: Jeff Roberson To: arch@freebsd.org Subject: New scheduler Message-ID: <20030123012620.E46974-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm sure many of you have seen me discussing my new scheduler in relation to the scheduler framework. I'd like to show what I have so far and get opinions/feedback. First, let me describe the features and general design of this scheduler. It is a queue switching O(1) scheduler much like solaris/linux/many others. It has per cpu run queues. It supports some notion of affinity. It is designed as a general purpose replacement for the current scheduler. It is not complete by any means. What is currently lacking is a good cpu balancing algorithm. I've been working on that for a little while now. The version I'm going to post has some temporary code that just decides where to place a proc at fork time. It never moves them after that. Its interactivity is very good in the situations that I've put it in. I have written some code to prove its latency, priority computations, nice effectiveness, etc. that I will post along with results as compared to the old scheduler and linux. There are some aspects of priority computation that I am very happy with and some that need more work. The most notable problem I have right now is what I'd call priority drift. The scheduler uses voluntary sleep time to calculate priority. A process which sleeps exactly one tick longer than it runs will eventually accumulate enough sleep time to reach the highest priority. I need to fix this. Oh, also, the pctcpu calculations are still a little off. I need to look into that. I have just started doing performance tests. Prior to this I was focusing on interactive response and priority calculation with nice. Some interesting early results: make -j4 buildworld on a 2 way Athlon 1800MP with one ata disk. new sched: 1933.193u 1156.398s 56:31.33 91.1% 2628+2106k 18752+4863io 8538pf+0w old sched: 2153.557u 1803.705s 48:25.07 136.2% 2462+1925k 17250+4666io 7113pf+0w What you can see here is that the sys time and user time were greatly reduced. By approx. 35% and 10% respectively. But, since we're not evenly balancing the load across both cpus the real time suffered. I don't expect the speedup to be this good once both cpus are well utilized due to memory bus contention. Anyway, I'm still waiting on single cpu results. If you have some free compute resources I'd love to have reports from different loads comparing this to the old scheduler. I'd also like feedback on how people would like to see this added to the build. You just need one file. It's available at http://www.chesapeake.net/~jroberson/sched_smp.c Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message