From owner-cvs-all@FreeBSD.ORG Sat Mar 29 08:04:30 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C4B137B401; Sat, 29 Mar 2003 08:04:30 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51AD243FBF; Sat, 29 Mar 2003 08:04:28 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA00817; Sun, 30 Mar 2003 02:04:21 +1000 Date: Sun, 30 Mar 2003 02:04:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: <20030330023855.Y11583@gamplex.bde.org> References: <20030327232742.GA80113@wantadilla.lemis.com> <20030328073513.GA20464@cirb503493.alcatel.com.au> <20030329235643.H11074@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: src-committers@freebsd.org cc: cvs-src@freebsd.org cc: Greg 'groggy' Lehey cc: Mike Silbersack cc: Nate Lawson cc: cvs-all@freebsd.org Subject: Re: Checksum/copy X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2003 16:04:32 -0000 On Sat, 29 Mar 2003, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Bruce Evans writes: > > > On a different note, support.s is a bloody mess. Once the dust has > > > settled, I'd like to go through it and reorder its contents a little. > > There is very little wrong with its order. > > I placed generic_page*() next to i686_pagezero(), which is right below > the various bzero() implementations. That's fine in the sense that it > is logically related to bzero(), but it's certainly not alphabetical. OK. > There's a comment right before generic_bzero() that says "bcopy > family", but bcopy() is miles away from that comment Oops. bzero() is in the bcopy() family, but I don't know how it got to be sorted before bcopy(). > > The microoptimization of making bzero a function pointer wasn't such a > > good idea. The main problem with undoing it is that this breaks binary > > compatibility. > > It looked completely bogus to me. I realize it breaks binary It was more useful on original i386's. It saves a whole branch instruction= =2E > IMHO, if specialized pagezero() and pagecopy() functions result in > measurably improved performance, they're worth the added complexity, > even if we're just talking about a few percent. I would buy a few percent of real time, but I think we're talking about a few percent of the copy/zero time, which is a few percent of the system time, which is a few percent of the real time. I tried makeworld with i686_pagezero() on an Athlon (!SMP). It's a pessimization on Athlon's and I got a measureable pessimization of 0.3% (6 seconds out of 1949). I don't consider this to be significant. Remaining tyle points taken to private mail. Bruce