From owner-cvs-src@FreeBSD.ORG Mon Nov 10 20:58:59 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43A0616A4D0 for ; Mon, 10 Nov 2003 20:58:59 -0800 (PST) Received: from vette.gigo.com (vette.gigo.com [216.218.228.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECAAC43FB1 for ; Mon, 10 Nov 2003 20:58:55 -0800 (PST) (envelope-from lioux@brturbo.com) Received: from 200.101.111.208 (200-101-111-208.bsace705.dsl.brasiltelecom.net.br [200.101.111.208]) by vette.gigo.com (Postfix) with ESMTP id 92BFA56D2 for ; Mon, 10 Nov 2003 20:49:36 -0800 (PST) Received: (qmail 26909 invoked by uid 1001); 11 Nov 2003 04:07:35 -0000 Message-ID: <20031111040735.26908.qmail@exxodus.fedaykin.here> Received: (qmail 47872 invoked from network); 9 Nov 2003 13:47:36 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 9 Nov 2003 13:47:36 -0000 Received: from pop3.uol.com.br by localhost with POP3 (fetchmail-6.2.5) for lioux-freebsd@localhost (single-drop); Sun, 09 Nov 2003 11:47:14 -0200 (BRST) Received: from peart.uol.com.br (172.26.5.218) by mtauol7.mail.sys.intranet (5.1.071) id 3EDB5C0C0207EE9F for lioux-freebsd@uol.com.br; Sun, 9 Nov 2003 10:46:39 -0300 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by storm4.uol.com.br (Postfix) with ESMTP id A8BB5E50A for ; Sun, 9 Nov 2003 11:46:37 -0200 (BRST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id D9ECC57775 for ; Sun, 9 Nov 2003 05:46:31 -0800 (PST) (envelope-from owner-src-committers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id B44AC16A527; Sun, 9 Nov 2003 05:46:29 -0800 (PST) Delivered-To: lioux@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 7472316A4D1; Sun, 9 Nov 2003 05:46:28 -0800 (PST) Delivered-To: src-committers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1FF316A4CE; Sun, 9 Nov 2003 05:45:55 -0800 (PST) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C6F843F93; Sun, 9 Nov 2003 05:45:55 -0800 (PST) (envelope-from bde@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.12.9/8.12.9) with ESMTP id hA9DjtXJ093879; Sun, 9 Nov 2003 05:45:55 -0800 (PST) (envelope-from bde@repoman.freebsd.org) Received: (from bde@localhost) by repoman.freebsd.org (8.12.9/8.12.9/Submit) id hA9Djt7S093878; Sun, 9 Nov 2003 05:45:55 -0800 (PST) (envelope-from bde) From: Bruce Evans Date: Sun, 9 Nov 2003 05:45:55 -0800 (PST) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG Subject: cvs commit: src/sys/kern sched_4bsd.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 04:58:59 -0000 bde 2003/11/09 05:45:55 PST FreeBSD src repository Modified files: sys/kern sched_4bsd.c Log: Quick fix for scaling of statclock ticks in the SMP case. As explained in the log message for kern_sched.c 1.83 (which should have been repo-copied to preserve history for this file), the (4BSD) scheduler algorithm only works right if stathz is nearly 128 Hz. The old commit lock said 64 Hz; the scheduler actually wants nearly 16 Hz but there was a scale factor of 4 to give the requirement of 64 Hz, and rev.1.83 changed the scale factor so that the requirement became 128 Hz. The change of the scale factor was incomplete in the SMP case. Then scheduling ticks are provided by smp_ncpu CPUs, and the scheduler cannot tell the difference between this and 1 CPU providing scheduling ticks smp_ncpu times faster, so we need another scale factor of smp_ncp or an algorithm change. This quick fix uses the scale factor without even trying to optimize the runtime divisions required for this as is done for the other scale factor. The main algorithmic problem is the clamp on the scheduling tick counts. This was 295; it is now approximately 295 * smp_ncpu. When the limit is reached, threads get free timeslices and scheduling becomes very unfair to the threads that don't hit the limit. The limit can be reached and maintained in the worst case if the load average is larger than (limit / effective_stathz - 1) / 2 = 0.65 now (was just 0.08 with 2 CPUs before this change), so there are algorithmic problems even for a load average of 1. Fortunately, the worst case isn't common enough for the problem to be very noticeable (it is mainly for niced CPU hogs competing with less nice CPU hogs). Revision Changes Path 1.28 +4 -0 src/sys/kern/sched_4bsd.c