From owner-freebsd-arch Sat Jan 25 23:25:14 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 A781C37B401; Sat, 25 Jan 2003 23:25:12 -0800 (PST) Received: from endless.iteration.net (endless.iteration.net [198.92.249.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B2A243E4A; Sat, 25 Jan 2003 23:25:12 -0800 (PST) (envelope-from keichii@endless.iteration.net) Received: by endless.iteration.net (Postfix, from userid 1001) id 7F1396CB836; Sun, 26 Jan 2003 01:25:11 -0600 (CST) Date: Sun, 26 Jan 2003 01:25:11 -0600 From: "Michael C. Wu" To: Robert Watson Cc: Steve Kargl , Jeff Roberson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler Message-ID: <20030126072511.GB97105@endless.iteration.net> Reply-To: "Michael C. Wu" References: <20030125045205.GA15091@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 User-Agent: Mutt/1.5.1i 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 On Sat, Jan 25, 2003 at 01:58:33PM -0500, Robert Watson scribbled: | > > It did not help. The load averages reported be top(1) | > > with the above change in palce are 7.86, 9.01, 8.72. Perhaps a better benchmark would be running simulataneous processes and timing them with a physical stopwatch. | > Jeff, it isn't the painkillers. The 2nd sentence should read "The load | > averages, reported by top(1) with the above change in place, are 7.86, | > 9.01, 8.72" | | Part of the problem is that the load average is a poor measure of system | utilization. Jeff's new scheduler may defer scheduling a process that's | ready to run to improve throughput and wait for a "better" CPU to run a | process on based on affinity. Potentially the result might be that the | run queues are (on average) deeper, and what the load average does is | measure the depth of the run queue over time. So for the moment, it's | probably best to disregard load average as a measure of performance. On | the other hand, actual interactivity regressions and performance changes | are very relevant. Load average is intended to capture the degree of | contention for CPU resources, but what exactly that means is always an | interesting question. After looking at the code somewhat (did not have enough time to read into the details), here are my humble suggestions. 1. Processor affinity is a two-edged sword, and optimizing a MP scheduler for a UP machine is almost a lost cause. Perhaps you can consider treating UP as a special case and look at the MP case without holding back. 2. Keep in mind that the Athlon MP you are using has a medium sized cache compared to large ones in Xeons and Alphas, and the P4 has trace caches built-in. Assuming that you have plans for future SMT architectures like p4-hyperthreads, your optimizations may fail. My suggestion is that you create a scoring matrix of sorts and dynamically test out run queue depth and affinity scores. (From experience, linear systems work the best.) After a period of time, a system will have "learned" to deal with the job that it is supposed to. Intel designed the P4 caches to be small so we can trash them, so to say. 3. In the scoring matrix, you may wish to give prioritizing affinity for certain processes like controlling the ata bus, mouse movements etc. Since you are creating a general purpose structure, remember that a lot of us use FreeBSD for scientific computing, with little disk I/O and lots of memory/cpu usage. Others like Yahoo! webfarms will want preference for disk I/O and network interface controlling priorities. If you are interested in the dynamic testing system, we can discuss this on IRC or in the follow-up emails. Regards, Michael -- Michael C. Wu keichii@{ iteration.net | FreeBSD.org | ece.utexas.edu | iis.sinica.edu.tw | ntugene.ibs.ntu.edu.tw } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message