From owner-freebsd-current@FreeBSD.ORG Wed Mar 3 14:32:52 2004 Return-Path: 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 8562716A4CF for ; Wed, 3 Mar 2004 14:32:52 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 3D64743D3F for ; Wed, 3 Mar 2004 14:32:52 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 1805 invoked by uid 1002); 3 Mar 2004 22:32:49 -0000 Received: from unknown (HELO ?10.4.1.17?) (64.58.1.252) by smtp.mho.net with SMTP; 3 Mar 2004 22:32:49 -0000 Date: Wed, 3 Mar 2004 15:35:12 -0700 (MST) From: Scott Long X-X-Sender: scottl@pooker.samsco.home To: Stefan =?iso-8859-1?Q?E=DFer?= In-Reply-To: <20040303221204.GA6234@StefanEsser.FreeBSD.org> Message-ID: <20040303153011.P27388@pooker.samsco.home> References: <20040301054623.U8264-100000@oahu.WURLDLINK.NET> <20040303221204.GA6234@StefanEsser.FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-current@freebsd.org cc: Robert Watson cc: Alexandre Sunny Kovalenko cc: Vincent Poy Subject: Re: buildworld times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 03 Mar 2004 22:32:52 -0000 On Wed, 3 Mar 2004, Stefan [iso-8859-1] E=DFer wrote: > > I do not understand, why 'ratio' comes out that different (92-103% vs. 13= 7-148%) > for 5.2.1 vs. -CURRENT (for -j4 and up, where HT plays a role). > > Is the process accounting different, or has the scheduler been changed to= make > better use of logical processors ??? ULE is better in 5.2-CURRENT than in RELENG_5_2. However, the significant change that is contributing to this is the improvements to make(1). Prior to 5.2-CURRENT, 'make -jX' would poll every 20ms for completed children, and then schedule new children. Now there is a simplistic SIGCHILD handler that allows new children to be scheduled immediately, and of course eliminates the overhead of the polling. Since buildworld is such a large consumer of fork/exec, it's not surprising that this change helps a lot. Scott