From owner-freebsd-arch@FreeBSD.ORG Sun Nov 21 16:17:58 2004 Return-Path: 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 4363616A4D6 for ; Sun, 21 Nov 2004 16:17:58 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23E5343E3A for ; Sun, 21 Nov 2004 15:55:23 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 27F8E5311; Sun, 21 Nov 2004 16:55:21 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 2D3DB530A; Sun, 21 Nov 2004 16:55:14 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 68313B85E; Sun, 21 Nov 2004 16:55:13 +0100 (CET) To: Ben Mesander References: <16795.57534.19299.407779@piglet.timing.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sun, 21 Nov 2004 16:55:13 +0100 In-Reply-To: <16795.57534.19299.407779@piglet.timing.com> (Ben Mesander's message of "Wed, 17 Nov 2004 16:37:34 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: freebsd-arch@freebsd.org Subject: Re: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 16:17:59 -0000 Ben Mesander writes: > It's come to my attention that libregex on FreeBSD is GPL'd - not > LGPL'd. I think it rather violates the POLA that anything that uses > regex_t and is compiled on FreeBSD ends up being covered by the terms > of the GPL. That's why it's called lib*gnu*regex. It is only used by other GPL software in the tree (specifically, cvs, grep and diff) > Has there been any thought given to moving to the modified Henry > Spencer regex library used in NetBSD & OpenBSD's libc? des@dwp ~% head -3 /usr/src/lib/libc/regex/COPYRIGHT Copyright 1992, 1993, 1994 Henry Spencer. All rights reserved. This software is not subject to any license of the American Telephone and Telegraph Company or of the Regents of the University of California. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Nov 21 18:06:11 2004 Return-Path: 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 237D016A4CE for ; Sun, 21 Nov 2004 18:06:11 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D550343D2D for ; Sun, 21 Nov 2004 18:06:10 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 31FB0A6D2A; Sun, 21 Nov 2004 10:06:08 -0800 (PST) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 82921-10; Sun, 21 Nov 2004 10:06:06 -0800 (PST) Received: from [192.168.1.2] (dsl081-069-073.sfo1.dsl.speakeasy.net [64.81.69.73]) by mail.trippynames.com (Postfix) with ESMTP id 894FDA5A89; Sun, 21 Nov 2004 10:06:06 -0800 (PST) In-Reply-To: References: <16795.57534.19299.407779@piglet.timing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <01E8B7B2-3BE8-11D9-905D-000A95C705DC@chittenden.org> Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Sun, 21 Nov 2004 10:06:03 -0800 To: des@des.no (=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=) X-Mailer: Apple Mail (2.619) cc: freebsd-arch@freebsd.org Subject: Re: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 18:06:11 -0000 >> Has there been any thought given to moving to the modified Henry >> Spencer regex library used in NetBSD & OpenBSD's libc? > > des@dwp ~% head -3 /usr/src/lib/libc/regex/COPYRIGHT > Copyright 1992, 1993, 1994 Henry Spencer. All rights reserved. > This software is not subject to any license of the American Telephone > and Telegraph Company or of the Regents of the University of > California. I think maybe what Ben was referring to was that Spencer has released an updated version of his regexp library that doesn't penalize wide character locales. I believe our current one performs terribly on everything but one byte character sets, whereas the newer Spencer library performs as well as one could hope with wide characters. The PostgreSQL group did some testing and found Spencers library to be the fastest wide character regexp engine while still maintaining very good levels of performance for single byte character sets. You'll have to check the PostgreSQL archives for details: it's been two years since that change was committed to their tree. -sc -- Sean Chittenden From owner-freebsd-arch@FreeBSD.ORG Sun Nov 21 22:59:10 2004 Return-Path: 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 F29AF16A4CE for ; Sun, 21 Nov 2004 22:59:09 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D15943D48 for ; Sun, 21 Nov 2004 22:59:09 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iALMuhRG026820; Sun, 21 Nov 2004 15:56:43 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 21 Nov 2004 15:57:18 -0700 (MST) Message-Id: <20041121.155718.68159788.imp@bsdimp.com> To: sean@chittenden.org From: "M. Warner Losh" In-Reply-To: <01E8B7B2-3BE8-11D9-905D-000A95C705DC@chittenden.org> References: <16795.57534.19299.407779@piglet.timing.com> <01E8B7B2-3BE8-11D9-905D-000A95C705DC@chittenden.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: des@des.no cc: freebsd-arch@freebsd.org Subject: Re: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 22:59:10 -0000 In message: <01E8B7B2-3BE8-11D9-905D-000A95C705DC@chittenden.org> Sean Chittenden writes: : >> Has there been any thought given to moving to the modified Henry : >> Spencer regex library used in NetBSD & OpenBSD's libc? : > : > des@dwp ~% head -3 /usr/src/lib/libc/regex/COPYRIGHT : > Copyright 1992, 1993, 1994 Henry Spencer. All rights reserved. : > This software is not subject to any license of the American Telephone : > and Telegraph Company or of the Regents of the University of : > California. : : I think maybe what Ben was referring to was that Spencer has released : an updated version of his regexp library that doesn't penalize wide : character locales. I believe our current one performs terribly on : everything but one byte character sets, whereas the newer Spencer : library performs as well as one could hope with wide characters. The : PostgreSQL group did some testing and found Spencers library to be the : fastest wide character regexp engine while still maintaining very good : levels of performance for single byte character sets. You'll have to : check the PostgreSQL archives for details: it's been two years since : that change was committed to their tree. -sc As well as a number of other fixes from NetBSD and OpenBSD. I'm pretty sure Ben doesn't care too much about wide character support... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 22 07:31:38 2004 Return-Path: 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 4885116A4CE; Mon, 22 Nov 2004 07:31:38 +0000 (GMT) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FCF043D1F; Mon, 22 Nov 2004 07:31:37 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) iAM7VX79030785 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 22 Nov 2004 18:31:35 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])iAM7VXxP047030; Mon, 22 Nov 2004 18:31:33 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)iAM7VWvw047029; Mon, 22 Nov 2004 18:31:32 +1100 (EST) (envelope-from pjeremy) Date: Mon, 22 Nov 2004 18:31:32 +1100 From: Peter Jeremy To: Poul-Henning Kamp Message-ID: <20041122073132.GW79646@cirb503493.alcatel.com.au> References: <76633.1100857077@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76633.1100857077@critter.freebsd.dk> User-Agent: Mutt/1.4.2i cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: [REVIEW/TEST] nanodelay() vs DELAY() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 07:31:38 -0000 On Fri, 2004-Nov-19 10:37:57 +0100, Poul-Henning Kamp wrote: > http://phk.freebsd.dk/patch/nanodelay.patch One buglet. In: +static void +initnanodelay(void *dummy) +{ + int i; + + for (i = 0; i < N_NANODELAY_BUCKETS; i++) { + nanodelay_funcs[i] = tc_nanodelay; + nanodelay_args[i] = i; + } The 2nd last line should be: + nanodelay_args[i] = i * (1 << N_NANODELAY_SHIFT); because the argument to tc_nanodelay() is in nsec. The fact that this doesn't show up in the graph suggests that you're not using tc_nanodelay() at all within the 0..8usec range. >Here is a plot which shows how DELAY() and nanodelay() perform on two >of my test-machines: > > http://phk.freebsd.dk/misc/nanodelay.png nanodelay() definitely looks much healthier than DELAY(). >A default routine spins on the timecounter using nanouptime(). How >well this works depends on which timecounter we use, but in general >we can trust it to be OK above a few microseconds. Your graph suggests that it's fairly good above about 200nsec even on equipment that is not blazingly fast. Have you looked at the granularity of tc_nanodelay() (and the likely granularity required by callers)? Is 8nsec reasonable given the inner loop of of tc_nanodelay()? Do you have any idea where the transition points between the various delay functions are? >The array takes up 9000 bytes on 32 bit and 17000 on 64 bit. AFAIK, all the FreeBSD architectures have 32-bit ints, so that should be 13,000 bytes for 64bit architectures. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Mon Nov 22 10:48:43 2004 Return-Path: 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 3AD6416A505 for ; Mon, 22 Nov 2004 10:48:41 +0000 (GMT) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC1F443D41 for ; Mon, 22 Nov 2004 10:48:40 +0000 (GMT) (envelope-from tjr@freebsd.org) Received: from robbins.dropbear.id.au (210.50.218.183) by smtp02.syd.iprimus.net.au (7.0.036) id 4192B046004CACC8; Mon, 22 Nov 2004 21:48:23 +1100 Received: from 192.168.0.64 (tim.robbins.dropbear.id.au [192.168.0.64]) by robbins.dropbear.id.au (Postfix) with ESMTP id 9FB854242; Mon, 22 Nov 2004 21:48:21 +1100 (EST) From: Tim Robbins To: Sean Chittenden In-Reply-To: <01E8B7B2-3BE8-11D9-905D-000A95C705DC@chittenden.org> References: <16795.57534.19299.407779@piglet.timing.com> <01E8B7B2-3BE8-11D9-905D-000A95C705DC@chittenden.org> Content-Type: text/plain Date: Mon, 22 Nov 2004 21:48:21 +1100 Message-Id: <1101120501.4321.24.camel@starshine.robbins.dropbear.id.au> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= cc: freebsd-arch@freebsd.org Subject: Re: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 10:48:43 -0000 On Sun, 2004-11-21 at 10:06 -0800, Sean Chittenden wrote: > >> Has there been any thought given to moving to the modified Henry > >> Spencer regex library used in NetBSD & OpenBSD's libc? > > > > des@dwp ~% head -3 /usr/src/lib/libc/regex/COPYRIGHT > > Copyright 1992, 1993, 1994 Henry Spencer. All rights reserved. > > This software is not subject to any license of the American Telephone > > and Telegraph Company or of the Regents of the University of > > California. > > I think maybe what Ben was referring to was that Spencer has released > an updated version of his regexp library that doesn't penalize wide > character locales. I believe our current one performs terribly on > everything but one byte character sets, whereas the newer Spencer > library performs as well as one could hope with wide characters. The > PostgreSQL group did some testing and found Spencers library to be the > fastest wide character regexp engine while still maintaining very good > levels of performance for single byte character sets. You'll have to > check the PostgreSQL archives for details: it's been two years since > that change was committed to their tree. -sc I think you'd be surprised at how poorly Henry Spencer's new code performs in all but the most contrived test cases, regardless of locale. You'll find that it performs especially poorly in multibyte locales because the matcher itself does not work directly with multibyte characters. Instead, the strings must first be entirely converted to wide characters, which means reading every single input byte, calling mbrtowc() on it, then storing the results in temporary scratch space, even if the characters don't participate in the match at all (e.g. all characters but the first when matching against patterns like "^x"). The FreeBSD 5 regex code only performs the conversion when necessary, and can often reject impossible matches without performing a single conversion in single-byte and UTF-8 locales. (This is assuming your input strings are given as multibyte character strings, as is common in UNIX, not wide character strings, as may be common in PostgreSQL). Tim From owner-freebsd-arch@FreeBSD.ORG Mon Nov 22 14:13:00 2004 Return-Path: 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 5D17816A4CE for ; Mon, 22 Nov 2004 14:13:00 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A850A43D5D for ; Mon, 22 Nov 2004 14:12:59 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 5B6175312; Mon, 22 Nov 2004 15:12:58 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id AB37C5311 for ; Mon, 22 Nov 2004 15:12:51 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 87269B85E; Mon, 22 Nov 2004 15:12:51 +0100 (CET) To: arch@freebsd.org From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 22 Nov 2004 15:12:51 +0100 Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 Subject: anticipatory I/O scheduling X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 14:13:00 -0000 I just ran across this paper and started wondering why I'd never heard of it before: To summarize, the authors rewrote the I/O scheduling algorithm in FreeBSD 4.3 and got massive performance improvements for Apache, and smaller but noticeable improvements for AFS and TPC-B. Has anyone looked into this? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Nov 22 14:17:47 2004 Return-Path: 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 440C016A5A3 for ; Mon, 22 Nov 2004 14:17:47 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B22A43D49 for ; Mon, 22 Nov 2004 14:17:47 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iAMEHg0b072935; Mon, 22 Nov 2004 06:17:42 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iAMEHgD8072934; Mon, 22 Nov 2004 06:17:42 -0800 (PST) (envelope-from rizzo) Date: Mon, 22 Nov 2004 06:17:42 -0800 From: Luigi Rizzo To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Message-ID: <20041122061742.A72907@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from des@des.no on Mon, Nov 22, 2004 at 03:12:51PM +0100 cc: arch@freebsd.org Subject: Re: anticipatory I/O scheduling X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 14:17:47 -0000 On Mon, Nov 22, 2004 at 03:12:51PM +0100, Dag-Erling Smørgrav wrote: > I just ran across this paper and started wondering why I'd never heard > of it before: > > > > To summarize, the authors rewrote the I/O scheduling algorithm in > FreeBSD 4.3 and got massive performance improvements for Apache, and > smaller but noticeable improvements for AFS and TPC-B. > > Has anyone looked into this? yes.... but what exactly do you want to know :) cheers luigi From owner-freebsd-arch@FreeBSD.ORG Mon Nov 22 14:40:02 2004 Return-Path: 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 2A5EC16A4CE for ; Mon, 22 Nov 2004 14:40:02 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id D95C543D58 for ; Mon, 22 Nov 2004 14:40:01 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id C4EE05312; Mon, 22 Nov 2004 15:40:00 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 2C4235311; Mon, 22 Nov 2004 15:39:53 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id C32B5B85E; Mon, 22 Nov 2004 15:39:52 +0100 (CET) To: Luigi Rizzo References: <20041122061742.A72907@xorpc.icir.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 22 Nov 2004 15:39:52 +0100 In-Reply-To: <20041122061742.A72907@xorpc.icir.org> (Luigi Rizzo's message of "Mon, 22 Nov 2004 06:17:42 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: arch@freebsd.org Subject: Re: anticipatory I/O scheduling X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 14:40:02 -0000 Luigi Rizzo writes: > On Mon, Nov 22, 2004 at 03:12:51PM +0100, Dag-Erling Sm=F8rgrav wrote: > > Has anyone looked into this? > yes.... but what exactly do you want to know :) why we haven't either integrated those patches or reimplemented them. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Nov 22 15:08:15 2004 Return-Path: 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 42A9216A4CE for ; Mon, 22 Nov 2004 15:08:15 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BE9543D1D for ; Mon, 22 Nov 2004 15:08:14 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iAMF8B0Z024319; Mon, 22 Nov 2004 16:08:12 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 22 Nov 2004 15:12:51 +0100." Date: Mon, 22 Nov 2004 16:08:11 +0100 Message-ID: <24318.1101136091@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: anticipatory I/O scheduling X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 15:08:15 -0000 In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >I just ran across this paper and started wondering why I'd never heard >of it before: > > > >To summarize, the authors rewrote the I/O scheduling algorithm in >FreeBSD 4.3 and got massive performance improvements for Apache, and >smaller but noticeable improvements for AFS and TPC-B. > >Has anyone looked into this? Yes. It's very hard to implement it correctly because you need a very rapid timer (order of microseconds). It is my plan to make disksort algorithms changeable on a per disk basis to encourage experimentation in this area. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Nov 23 02:28:33 2004 Return-Path: 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 D63C816A4CE for ; Tue, 23 Nov 2004 02:28:33 +0000 (GMT) Received: from mail.fryazino.net (10.253.140.62.fiord.ru [62.140.253.10]) by mx1.FreeBSD.org (Postfix) with SMTP id BB73043D55 for ; Tue, 23 Nov 2004 02:28:32 +0000 (GMT) (envelope-from aik@fryazino.net) Received: (qmail 30115 invoked from network); 23 Nov 2004 02:18:08 -0000 Received: from gate.fryazino.net (HELO 172.16.2.6) (62.140.253.5) by mail.fryazino.net with SMTP; 23 Nov 2004 02:18:07 -0000 Date: Tue, 23 Nov 2004 05:24:52 +0300 From: "." X-Mailer: The Bat! (v1.61) X-Priority: 3 (Normal) Message-ID: <1452678363.20041123052452@fryazino.net> To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: I need help with serial driver X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "." List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 02:28:34 -0000 Greetings! I did not find in "BSD Developers handbook" or anywhere else theese precious bits of information: 1. What methods should character driver ( /dev/cuaa or similar) have? 2. How application requests (open/read/ioctl/etc.) are mapped to methods of the driver? 3. Are there any special functions besides generic file I/O operations (apart from ioctl(2))? Or are there any "special cases" of ioctl apart from what is covered by man page? I need to utlize the abilities of /dev/cuua to their extreme, but I do not want to rewrite the standard one. Sorry for troubling you, Igor From owner-freebsd-arch@FreeBSD.ORG Tue Nov 23 16:27:10 2004 Return-Path: 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 3B88D16A4CE for ; Tue, 23 Nov 2004 16:27:10 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 8E3B343D3F for ; Tue, 23 Nov 2004 16:27:09 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 6637 invoked by uid 89); 23 Nov 2004 16:27:05 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 23 Nov 2004 16:27:05 -0000 Received: (qmail 32729 invoked by uid 89); 23 Nov 2004 16:25:05 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 23 Nov 2004 16:25:05 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id iANGP45R046172; Tue, 23 Nov 2004 11:25:05 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: "freebsd-arch@freebsd.org" Content-Type: text/plain Message-Id: <1101227104.26313.9422.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 23 Nov 2004 11:25:04 -0500 Content-Transfer-Encoding: 7bit cc: Robert Watson Subject: macro benchmark for mutex locks needed. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 16:27:10 -0000 I have a bunch of ideas to speed up spin and mutex locks somewhat. For this I need benchmarks to test different modifications. While the micro-benchmark from rwatson@ is a good way to quickly test modifications to weed out unlikely candidates - jhb@ tests have shown that micro and macro-benchmarks do not always show the same result. Running benchmarks and booting takes a lot of time. Since this is NOT one my favorite tasks I want to run generally accepted benchmarks so I can test (boot) each modification exactly once for each test machine. If you think I should run certain benchmarks with certain parameters please tell me BEFORE I start testing! Thanks Stephan From owner-freebsd-arch@FreeBSD.ORG Tue Nov 23 16:51:37 2004 Return-Path: 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 775E716A4CE; Tue, 23 Nov 2004 16:51:37 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07A0243D49; Tue, 23 Nov 2004 16:51:37 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iANGno70091129; Tue, 23 Nov 2004 11:49:50 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iANGno2k091126; Tue, 23 Nov 2004 16:49:50 GMT (envelope-from robert@fledge.watson.org) Date: Tue, 23 Nov 2004 16:49:50 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Stephan Uphoff In-Reply-To: <1101227104.26313.9422.camel@palm.tree.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "freebsd-arch@freebsd.org" Subject: Re: macro benchmark for mutex locks needed. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 16:51:37 -0000 On Tue, 23 Nov 2004, Stephan Uphoff wrote: > I have a bunch of ideas to speed up spin and mutex locks somewhat. For > this I need benchmarks to test different modifications. > > While the micro-benchmark from rwatson@ is a good way to quickly test > modifications to weed out unlikely candidates - jhb@ tests have shown > that micro and macro-benchmarks do not always show the same result. > > Running benchmarks and booting takes a lot of time. Since this is NOT > one my favorite tasks I want to run generally accepted benchmarks so I > can test (boot) each modification exactly once for each test machine. > > If you think I should run certain benchmarks with certain parameters > please tell me BEFORE I start testing! I like to use netblast from src/tools/tools/netrate/netblast. It attempts to send packets as quickly as possible on a network interface, which is a CPU-intensive operation that is very sensitive to the cost of synchronization. On an SMP system, it also generates a moderate ithread load as the gig-e interface transmits, and that ithread will often contend on the network interface driver lock with the running netblast thread. As such, it changes that affect the cost and handling of contention are also visible in this benchmark. With the synchronization micro-benchmark, I see spin locks on SMP being faster with the atomic release removed, but in the netblast test, I see those spinlocks as slower on SMP, since they behave less well under contention. (The above with 64-bit if_em cards on a dual-Xeon). Note that you'll want to make sure netreceive is running on a second box, or that you're sending to the broadcast address, or the icmp errors will substantially quench your send ability due to the asynchronouse report of the port closed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Tue Nov 23 18:17:20 2004 Return-Path: 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 52E0116A4CE for ; Tue, 23 Nov 2004 18:17:20 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A11743D1F for ; Tue, 23 Nov 2004 18:17:20 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 072FA72DF8; Tue, 23 Nov 2004 10:17:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 04C2472DCB; Tue, 23 Nov 2004 10:17:20 -0800 (PST) Date: Tue, 23 Nov 2004 10:17:19 -0800 (PST) From: Doug White To: "." In-Reply-To: <1452678363.20041123052452@fryazino.net> Message-ID: <20041123101632.G86435@carver.gumbysoft.com> References: <1452678363.20041123052452@fryazino.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: I need help with serial driver X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 18:17:20 -0000 On Tue, 23 Nov 2004, . wrote: > Greetings! > I did not find in "BSD Developers handbook" or anywhere else theese > precious bits of information: > 1. What methods should character driver ( /dev/cuaa or similar) have? > 2. How application requests (open/read/ioctl/etc.) are mapped to > methods of the driver? > 3. Are there any special functions besides generic file I/O operations > (apart from ioctl(2))? Or are there any "special cases" of ioctl apart > from what is covered by man page? The scripts in /usr/share/examples/drivers/ may be of use to you. > I need to utlize the abilities of /dev/cuua to their extreme, but I > do not want to rewrite the standard one. Yet you are asking how. :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Nov 23 18:55:45 2004 Return-Path: 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 B4A2316A4CE for ; Tue, 23 Nov 2004 18:55:45 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 30FC743D41 for ; Tue, 23 Nov 2004 18:55:45 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 4469 invoked by uid 89); 23 Nov 2004 18:55:43 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 23 Nov 2004 18:55:43 -0000 Received: (qmail 28849 invoked by uid 89); 23 Nov 2004 18:52:51 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 23 Nov 2004 18:52:51 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id iANIqo5R046800; Tue, 23 Nov 2004 13:52:50 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Phil Brennan In-Reply-To: References: <1101227104.26313.9422.camel@palm.tree.com> Content-Type: text/plain Message-Id: <1101235970.26313.9901.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 23 Nov 2004 13:52:50 -0500 Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" Subject: Re: macro benchmark for mutex locks needed. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 18:55:45 -0000 On Tue, 2004-11-23 at 11:32, Phil Brennan wrote: > Could you post up some of your ideas to achieve these speedups? I'm > fascinated by this area, because it is such a crucial one if freebsd > is to perform well after all the work in unwinding giant. Mostly boring stuff like making sure that important mutexes live in their own cache line to avoid false sharing and tweaking some code to avoid unnecessary invalidation of cache lines. There are also some architecture specific assembly tweaks that I like to try. Maybe a few hacks for dynamic run time patching to allow processor specific and SMP/UP optimizations on a GENERIC kernel. Replacing cli/sti with a spl() style interrupt enabler/disabler for i386 is also something I would like to test to speed up spin locks. Restoring single thread wakeup for sleep mutexes is also on the list. Once I start digging I will probably find more things to try. > > On Tue, 23 Nov 2004 11:25:04 -0500, Stephan Uphoff wrote: > > I have a bunch of ideas to speed up spin and mutex locks somewhat. > > For this I need benchmarks to test different modifications. > > > > While the micro-benchmark from rwatson@ is a good way to quickly test > > modifications to weed out unlikely candidates - jhb@ tests have shown > > that micro and macro-benchmarks do not always show the same result. > > > > Running benchmarks and booting takes a lot of time. > > Since this is NOT one my favorite tasks I want to run generally accepted > > benchmarks so I can test (boot) each modification exactly once for each > > test machine. > > > > If you think I should run certain benchmarks with certain parameters > > please tell me BEFORE I start testing! > > > > Thanks From owner-freebsd-arch@FreeBSD.ORG Tue Nov 23 20:00:01 2004 Return-Path: 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 B522916A4CE for ; Tue, 23 Nov 2004 20:00:01 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id EE31A43D45 for ; Tue, 23 Nov 2004 20:00:00 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 7238 invoked by uid 89); 23 Nov 2004 19:59:59 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 23 Nov 2004 19:59:59 -0000 Received: (qmail 28983 invoked by uid 89); 23 Nov 2004 19:56:21 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 23 Nov 2004 19:56:21 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id iANJuK5R047172; Tue, 23 Nov 2004 14:56:20 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Robert Watson In-Reply-To: References: Content-Type: text/plain Message-Id: <1101239780.26313.10158.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 23 Nov 2004 14:56:20 -0500 Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" Subject: Re: macro benchmark for mutex locks needed. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 20:00:01 -0000 On Tue, 2004-11-23 at 11:49, Robert Watson wrote: > On Tue, 23 Nov 2004, Stephan Uphoff wrote: > > > I have a bunch of ideas to speed up spin and mutex locks somewhat. For > > this I need benchmarks to test different modifications. > > > > While the micro-benchmark from rwatson@ is a good way to quickly test > > modifications to weed out unlikely candidates - jhb@ tests have shown > > that micro and macro-benchmarks do not always show the same result. > > > > Running benchmarks and booting takes a lot of time. Since this is NOT > > one my favorite tasks I want to run generally accepted benchmarks so I > > can test (boot) each modification exactly once for each test machine. > > > > If you think I should run certain benchmarks with certain parameters > > please tell me BEFORE I start testing! > > I like to use netblast from src/tools/tools/netrate/netblast. It attempts > to send packets as quickly as possible on a network interface, which is a > CPU-intensive operation that is very sensitive to the cost of > synchronization. On an SMP system, it also generates a moderate ithread > load as the gig-e interface transmits, and that ithread will often contend > on the network interface driver lock with the running netblast thread. As > such, it changes that affect the cost and handling of contention are also > visible in this benchmark. With the synchronization micro-benchmark, I > see spin locks on SMP being faster with the atomic release removed, but in > the netblast test, I see those spinlocks as slower on SMP, since they > behave less well under contention. > > (The above with 64-bit if_em cards on a dual-Xeon). Note that you'll want > to make sure netreceive is running on a second box, or that you're sending > to the broadcast address, or the icmp errors will substantially quench > your send ability due to the asynchronouse report of the port closed. Mhh... My initial SMP test machine will be a Dell 1600SC dual-Xeon (P4 - 2.8 GHz/400MHz bus). It has a build in em Ethernet interface. Unfortunately it is only a 82540EM / 32bit chip and it shares the PCI bus with a few 33MHz PCI cards :-(. The machine has an unused pci bus with free PCI-X slot but I would need to order a server card. What is you normal data rate with this test - any chance that the 82540EM will be sufficient? The data sink will be a 32bit em card with an ancient slow P4 processor using a cross-over cable. Since this combination is probably not able to sink enough data I plan to add a dummy static arp address for a dummy remote IP address to the SMP machine. This should keep the the data sink's em card from actually filling the receive buffers. Since this takes the pci bus and the slow processor out of the equation this should be a perfect data sink - right? From owner-freebsd-arch@FreeBSD.ORG Tue Nov 23 22:49:54 2004 Return-Path: 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 6E0F616A4CE for ; Tue, 23 Nov 2004 22:49:54 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D858443D2D for ; Tue, 23 Nov 2004 22:49:53 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iANMm7av099071; Tue, 23 Nov 2004 17:48:07 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iANMm7tm099068; Tue, 23 Nov 2004 22:48:07 GMT (envelope-from robert@fledge.watson.org) Date: Tue, 23 Nov 2004 22:48:07 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Stephan Uphoff In-Reply-To: <1101235970.26313.9901.camel@palm.tree.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Phil Brennan cc: "freebsd-arch@freebsd.org" Subject: Re: macro benchmark for mutex locks needed. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 22:49:54 -0000 On Tue, 23 Nov 2004, Stephan Uphoff wrote: > On Tue, 2004-11-23 at 11:32, Phil Brennan wrote: > > Could you post up some of your ideas to achieve these speedups? I'm > > fascinated by this area, because it is such a crucial one if freebsd > > is to perform well after all the work in unwinding giant. > > Mostly boring stuff like making sure that important mutexes live in > their own cache line to avoid false sharing and tweaking some code to > avoid unnecessary invalidation of cache lines. There are also some > architecture specific assembly tweaks that I like to try. Maybe a few > hacks for dynamic run time patching to allow processor specific and > SMP/UP optimizations on a GENERIC kernel. Replacing cli/sti with a > spl() style interrupt enabler/disabler for i386 is also something I > would like to test to speed up spin locks. Restoring single thread > wakeup for sleep mutexes is also on the list. Once I start digging I > will probably find more things to try. If you want an excellent candidate for cache line contention foo, you might take a glance at the uma_pcpu_mtx array in UMA. This may well be obsoleted by my changed to UMA to use critical sections instead of mutexes here, but it would be very interesting to see what happens here since it's an example of high probability simultaneous access/low probability contention mutexes that are packed tightly. The impact on performance, if significant, would be measurable using a broad range of benchmarks. Some other interesting candidates might be: - Mutex pool mutexes in kern_mtxpool.c. - The sockbuf send/receive mutexes in struct socket, and in fact the struct sockbufs themselves. We might also want to investigate a struct mtx_with_pad that includes the necessary padding, to be used for static mutex structures that are probably getting packed with the oddest stuff. I.e., sigio_mtx, devmtx, mac_policy_mtx, malloc_mtx, lockbuilder_pool, tid_lock, callout_lock, cache_lock. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Wed Nov 24 08:40:54 2004 Return-Path: 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 192F516A4CE; Wed, 24 Nov 2004 08:40:54 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6122943D2F; Wed, 24 Nov 2004 08:40:53 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iAO8enU5061436; Wed, 24 Nov 2004 09:40:51 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 22 Nov 2004 18:31:32 +1100." <20041122073132.GW79646@cirb503493.alcatel.com.au> Date: Wed, 24 Nov 2004 09:40:49 +0100 Message-ID: <61435.1101285649@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: [REVIEW/TEST] nanodelay() vs DELAY() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 08:40:54 -0000 In message <20041122073132.GW79646@cirb503493.alcatel.com.au>, Peter Jeremy wri tes: >The fact that this doesn't show up in the graph suggests that you're >not using tc_nanodelay() at all within the 0..8usec range. Right, but I can't trust that to be the case as CPUs get faster. Originally I considered having MD routines registered also, stuff like doing an "inb()" on i386 etc. As it transpired the exponential nature of the nanodelay_loopcall2() function makes this unnecessary. >Your graph suggests that it's fairly good above about 200nsec even on >equipment that is not blazingly fast. Don't let the log-log scale deceive you. being 50% wrong doesn't look like much. >Have you looked at the granularity of tc_nanodelay() (and the likely >granularity required by callers)? Is 8nsec reasonable given the >inner loop of of tc_nanodelay()? I'm actually considering making it 32nsec based on a 33MHz PCI speed. >Do you have any idea where the transition points between the various >delay functions are? If you boot -v it will tell you. >>The array takes up 9000 bytes on 32 bit and 17000 on 64 bit. > >AFAIK, all the FreeBSD architectures have 32-bit ints, so that should >be 13,000 bytes for 64bit architectures. Still, that's an awful lot for an old ass'y programmer like me :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 24 16:33:46 2004 Return-Path: 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 B1CA016A4D2; Wed, 24 Nov 2004 16:33:46 +0000 (GMT) Received: from r1a.corp.servercentral.net (exchange.corp.servercentral.net [66.225.247.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id A64CA43D5E; Wed, 24 Nov 2004 16:33:45 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from mail pickup service by r1a.corp.servercentral.net with Microsoft SMTPSVC; Wed, 24 Nov 2004 10:33:38 -0600 Received: from demandindustries.net ([161.58.224.124]) by r1a.corp.servercentral.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 02:41:38 -0600 Received: from scanner.servercentral.net (scanner.servercentral.net [66.225.196.47]) by demandindustries.net (8.12.11/8.12.9) with ESMTP id iAO8fb6N024180 for ; Wed, 24 Nov 2004 02:41:38 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by scanner.servercentral.net (Postfix) with ESMTP id 85E4B8700C7 for ; Wed, 24 Nov 2004 02:41:37 -0600 (CST) Received: from scanner.servercentral.net ([127.0.0.1]) by localhost (mb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01734-04 for ; Wed, 24 Nov 2004 02:41:36 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by scanner.servercentral.net (Postfix) with ESMTP id AE3888700C3 for ; Wed, 24 Nov 2004 02:41:36 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id E2B0256BFC; Wed, 24 Nov 2004 08:41:22 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 651CD16A4D2; Wed, 24 Nov 2004 08:41:15 +0000 (GMT) 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 192F516A4CE; Wed, 24 Nov 2004 08:40:54 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6122943D2F; Wed, 24 Nov 2004 08:40:53 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iAO8enU5061436; Wed, 24 Nov 2004 09:40:51 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 22 Nov 2004 18:31:32 +1100." <20041122073132.GW79646@cirb503493.alcatel.com.au> Date: Wed, 24 Nov 2004 09:40:49 +0100 Message-ID: <61435.1101285649@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-Virus-Scanned: by amavis for cervercentral.net X-OriginalArrivalTime: 24 Nov 2004 08:41:38.0948 (UTC) FILETIME=[6A107440:01C4D201] cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: [REVIEW/TEST] nanodelay() vs DELAY() X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:33:47 -0000 In message <20041122073132.GW79646@cirb503493.alcatel.com.au>, Peter Jeremy wri tes: >The fact that this doesn't show up in the graph suggests that you're >not using tc_nanodelay() at all within the 0..8usec range. Right, but I can't trust that to be the case as CPUs get faster. Originally I considered having MD routines registered also, stuff like doing an "inb()" on i386 etc. As it transpired the exponential nature of the nanodelay_loopcall2() function makes this unnecessary. >Your graph suggests that it's fairly good above about 200nsec even on >equipment that is not blazingly fast. Don't let the log-log scale deceive you. being 50% wrong doesn't look like much. >Have you looked at the granularity of tc_nanodelay() (and the likely >granularity required by callers)? Is 8nsec reasonable given the >inner loop of of tc_nanodelay()? I'm actually considering making it 32nsec based on a 33MHz PCI speed. >Do you have any idea where the transition points between the various >delay functions are? If you boot -v it will tell you. >>The array takes up 9000 bytes on 32 bit and 17000 on 64 bit. > >AFAIK, all the FreeBSD architectures have 32-bit ints, so that should >be 13,000 bytes for 64bit architectures. Still, that's an awful lot for an old ass'y programmer like me :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Thu Nov 25 13:20:48 2004 Return-Path: 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 DB7D716A4CE for ; Thu, 25 Nov 2004 13:20:48 +0000 (GMT) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21C7943D5D for ; Thu, 25 Nov 2004 13:20:48 +0000 (GMT) (envelope-from ursul@lodder.xs4all.nl) Received: from MAINBOX (lodder.xs4all.nl [213.84.56.215]) by smtp-vbr11.xs4all.nl (8.12.11/8.12.11) with SMTP id iAPDKkPx091283 for ; Thu, 25 Nov 2004 14:20:47 +0100 (CET) (envelope-from ursul@lodder.xs4all.nl) Message-ID: <000801c4d2f1$913d9520$9600000a@MAINBOX> From: "Ursul Lodder" To: Date: Thu, 25 Nov 2004 14:20:43 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: FreeBSD on IBM 350-H ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2004 13:20:49 -0000 Hi there at FreeBSD.org, is any of the versions of FReeBSD suitable to = use for installation on a IBM RS6000 (type 350-H)?=20 Hope to hear from you soon, with kind regards, Serge Lodder