From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 07:00:41 2007 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B6FE16A402 for ; Sun, 25 Feb 2007 07:00:41 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.freebsd.org (Postfix) with ESMTP id 245F213C481 for ; Sun, 25 Feb 2007 07:00:41 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id AEE70DB83; Sun, 25 Feb 2007 09:00:37 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgI9TzaVlJBk; Sun, 25 Feb 2007 09:00:32 +0200 (EET) Received: from [193.64.42.234] (dyn234.helenius.fi [193.64.42.234]) by silver.he.iki.fi (Postfix) with ESMTP; Sun, 25 Feb 2007 09:00:32 +0200 (EET) Message-ID: <45E13410.7020505@he.iki.fi> Date: Sun, 25 Feb 2007 09:00:32 +0200 From: Petri Helenius User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Kris Kennaway References: <20070224215508.GA41968@xor.obsecurity.org> In-Reply-To: <20070224215508.GA41968@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@FreeBSD.org Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 07:00:41 -0000 Kris Kennaway wrote: > > This shows the graph of MySQL transactions/second performed by a > multi-threaded client workload against a local MySQL database with > varying numbers of client threads, with identically configured FreeBSD > and Linux systems on the same machine. > How does that compare to 6.2-RELEASE performance? Pete From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 07:19:48 2007 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA8E716A401 for ; Sun, 25 Feb 2007 07:19:48 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D726013C491 for ; Sun, 25 Feb 2007 07:19:48 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 2F8951A4D81; Sat, 24 Feb 2007 23:19:48 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 647325421E; Sun, 25 Feb 2007 02:19:46 -0500 (EST) Date: Sun, 25 Feb 2007 02:19:46 -0500 From: Kris Kennaway To: Petri Helenius Message-ID: <20070225071946.GA48242@xor.obsecurity.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E13410.7020505@he.iki.fi> User-Agent: Mutt/1.4.2.2i Cc: freebsd-performance@FreeBSD.org, Kris Kennaway Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 07:19:49 -0000 On Sun, Feb 25, 2007 at 09:00:32AM +0200, Petri Helenius wrote: > Kris Kennaway wrote: > > > >This shows the graph of MySQL transactions/second performed by a > >multi-threaded client workload against a local MySQL database with > >varying numbers of client threads, with identically configured FreeBSD > >and Linux systems on the same machine. > > > How does that compare to 6.2-RELEASE performance? Much better. Fixing filedesc locking was key. Kris From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 08:41:30 2007 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 951B016A400 for ; Sun, 25 Feb 2007 08:41:30 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.freebsd.org (Postfix) with ESMTP id 4A10F13C467 for ; Sun, 25 Feb 2007 08:41:30 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id 80963359F; Sun, 25 Feb 2007 10:41:24 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puNgXJQaZRsT; Sun, 25 Feb 2007 10:41:19 +0200 (EET) Received: from [193.64.42.234] (dyn234.helenius.fi [193.64.42.234]) by silver.he.iki.fi (Postfix) with ESMTP; Sun, 25 Feb 2007 10:41:19 +0200 (EET) Message-ID: <45E14BAD.80909@he.iki.fi> Date: Sun, 25 Feb 2007 10:41:17 +0200 From: Petri Helenius User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Kris Kennaway References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> In-Reply-To: <20070225071946.GA48242@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@FreeBSD.org Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 08:41:30 -0000 Kris Kennaway wrote: > On Sun, Feb 25, 2007 at 09:00:32AM +0200, Petri Helenius wrote: > >> Kris Kennaway wrote: >> >>> This shows the graph of MySQL transactions/second performed by a >>> multi-threaded client workload against a local MySQL database with >>> varying numbers of client threads, with identically configured FreeBSD >>> and Linux systems on the same machine. >>> >>> >> How does that compare to 6.2-RELEASE performance? >> > > Much better. Fixing filedesc locking was key. > > If there is extra cycles on the same hardware, a performance comparison graph would be great. Pete From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 08:47:39 2007 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4194916A401 for ; Sun, 25 Feb 2007 08:47:39 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2F28713C478 for ; Sun, 25 Feb 2007 08:47:39 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 15E041A4D80; Sun, 25 Feb 2007 00:47:39 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 478FF51446; Sun, 25 Feb 2007 03:47:38 -0500 (EST) Date: Sun, 25 Feb 2007 03:47:37 -0500 From: Kris Kennaway To: Petri Helenius Message-ID: <20070225084737.GA49231@xor.obsecurity.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E14BAD.80909@he.iki.fi> User-Agent: Mutt/1.4.2.2i Cc: freebsd-performance@FreeBSD.org, Kris Kennaway Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 08:47:39 -0000 On Sun, Feb 25, 2007 at 10:41:17AM +0200, Petri Helenius wrote: > Kris Kennaway wrote: > >On Sun, Feb 25, 2007 at 09:00:32AM +0200, Petri Helenius wrote: > > > >>Kris Kennaway wrote: > >> > >>>This shows the graph of MySQL transactions/second performed by a > >>>multi-threaded client workload against a local MySQL database with > >>>varying numbers of client threads, with identically configured FreeBSD > >>>and Linux systems on the same machine. > >>> > >>> > >>How does that compare to 6.2-RELEASE performance? > >> > > > >Much better. Fixing filedesc locking was key. > > > > > If there is extra cycles on the same hardware, a performance comparison > graph would be great. See the links in my posting ;) Kris From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 08:55:06 2007 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E9F416A400 for ; Sun, 25 Feb 2007 08:55:06 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.freebsd.org (Postfix) with ESMTP id 56DAC13C467 for ; Sun, 25 Feb 2007 08:55:06 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id 55665359F; Sun, 25 Feb 2007 10:55:05 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtZNRuorNTI0; Sun, 25 Feb 2007 10:55:01 +0200 (EET) Received: from [193.64.42.234] (dyn234.helenius.fi [193.64.42.234]) by silver.he.iki.fi (Postfix) with ESMTP; Sun, 25 Feb 2007 10:55:01 +0200 (EET) Message-ID: <45E14EE4.3010208@he.iki.fi> Date: Sun, 25 Feb 2007 10:55:00 +0200 From: Petri Helenius User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Kris Kennaway References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> In-Reply-To: <20070225084737.GA49231@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@FreeBSD.org Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 08:55:06 -0000 With this great progress, it would be even greater if there would be way to run virtualization (Xen) when 7.0 hits the street. Pete From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 09:08:36 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBCB816A401 for ; Sun, 25 Feb 2007 09:08:36 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 993CB13C48D for ; Sun, 25 Feb 2007 09:08:32 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HLFMl-0001or-41 for freebsd-performance@freebsd.org; Sun, 25 Feb 2007 10:08:23 +0100 Received: from 194.204.57.56 ([194.204.57.56]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Feb 2007 10:08:23 +0100 Received: from ivoras by 194.204.57.56 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Feb 2007 10:08:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Sun, 25 Feb 2007 11:08:20 +0100 Lines: 15 Message-ID: References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 194.204.57.56 User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) In-Reply-To: <20070225084737.GA49231@xor.obsecurity.org> X-Enigmail-Version: 0.94.1.0 Sender: news Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 09:08:36 -0000 Kris Kennaway wrote: >>>> How does that compare to 6.2-RELEASE performance? >>>> >>> Much better. Fixing filedesc locking was key. >>> >>> >> If there is extra cycles on the same hardware, a performance comparison >> graph would be great. > > See the links in my posting ;) I think he means graphs between 6-stable and 7-current - it would be very nice to see those on the same machine, mysql configuration, etc. (at the very least to clearly show why people should upgrade :) ). From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 09:29:50 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2D7616A403 for ; Sun, 25 Feb 2007 09:29:50 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D00BE13C474 for ; Sun, 25 Feb 2007 09:29:50 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 45DA01A3C1A; Sun, 25 Feb 2007 01:29:50 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2C05E517C9; Sun, 25 Feb 2007 04:29:48 -0500 (EST) Date: Sun, 25 Feb 2007 04:29:47 -0500 From: Kris Kennaway To: Ivan Voras Message-ID: <20070225092947.GA49489@xor.obsecurity.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-performance@freebsd.org Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 09:29:51 -0000 On Sun, Feb 25, 2007 at 11:08:20AM +0100, Ivan Voras wrote: > Kris Kennaway wrote: > > >>>> How does that compare to 6.2-RELEASE performance? > >>>> > >>> Much better. Fixing filedesc locking was key. > >>> > >>> > >> If there is extra cycles on the same hardware, a performance comparison > >> graph would be great. > > > > See the links in my posting ;) > > I think he means graphs between 6-stable and 7-current - it would be > very nice to see those on the same machine, mysql configuration, etc. > (at the very least to clearly show why people should upgrade :) ). 6.2 and 7.0 CVS sources (which are graphed on Jeff's blog and my webpage linked there) are unlikely to differ much: as I said, filedesc locking was key to fixing performance here. I'm sure we'll be promoting this improvement heavily when 7.0 enters release cycle, to encourage people to consider upgrading. Kris From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 16:17:03 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E820916A403 for ; Sun, 25 Feb 2007 16:17:03 +0000 (UTC) (envelope-from lists@stringsutils.com) Received: from zoraida.natserv.net (p65-147.acedsl.com [66.114.65.147]) by mx1.freebsd.org (Postfix) with ESMTP id A993313C441 for ; Sun, 25 Feb 2007 16:17:03 +0000 (UTC) (envelope-from lists@stringsutils.com) Received: from zoraida.natserv.net (localhost.natserv.net [127.0.0.1]) by zoraida.natserv.net (Postfix) with ESMTP id AEC86C317 for ; Sun, 25 Feb 2007 11:16:57 -0500 (EST) Received: by zoraida.natserv.net (Postfix, from userid 58) id F4011C2EC; Sun, 25 Feb 2007 11:16:56 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on zoraida.natserv.net X-Spam-Level: X-Spam-Status: No, score=1.0 required=4.0 tests=RCVD_IN_FIVETENSRC,SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * 1.0 RCVD_IN_FIVETENSRC RBL: Received via a relay in Five Ten block list * [66.114.65.147 listed in blackholes.five-ten-sg.com] Received: from zoraida.natserv.net (zoraida.natserv.net [66.114.65.147]) by zoraida.natserv.net (Postfix) with ESMTP id 6B7F8C2AF; Sun, 25 Feb 2007 11:16:54 -0500 (EST) References: <0e2001c7574c$26bc15a0$b3db87d4@multiplay.co.uk> <20070224005748.GA25295@xor.obsecurity.org> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Francisco Reyes To: Kris Kennaway Date: Sun, 25 Feb 2007 11:16:54 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-performance@freebsd.org, Steven Hartland Subject: Re: FreeBSD Scaling on 6.2-RELEASE? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 16:17:04 -0000 Kris Kennaway writes: > Actually it will help the DB side, when you have multiple simultaneous > transactions - that's the point :) A little confused. Does this mean FreeBSD will split the threads into multiple CPUs? Or you meant the DB will do better because the load from other programs will be split across the different CPUs? From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 17:14:52 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94A2C16A400 for ; Sun, 25 Feb 2007 17:14:52 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.freebsd.org (Postfix) with ESMTP id 4B7B713C481 for ; Sun, 25 Feb 2007 17:14:48 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id AFB99359F; Sun, 25 Feb 2007 19:14:46 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgTJonqcmp8I; Sun, 25 Feb 2007 19:14:39 +0200 (EET) Received: from [193.64.42.234] (dyn234.helenius.fi [193.64.42.234]) by silver.he.iki.fi (Postfix) with ESMTP; Sun, 25 Feb 2007 19:14:39 +0200 (EET) Message-ID: <45E1C3FC.6040905@he.iki.fi> Date: Sun, 25 Feb 2007 19:14:36 +0200 From: Petri Helenius User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Francisco Reyes References: <0e2001c7574c$26bc15a0$b3db87d4@multiplay.co.uk> <20070224005748.GA25295@xor.obsecurity.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, Steven Hartland , Kris Kennaway Subject: Re: FreeBSD Scaling on 6.2-RELEASE? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 17:14:52 -0000 Francisco Reyes wrote: > > A little confused. > Does this mean FreeBSD will split the threads into multiple CPUs? The point in threading is that different threads can execute simultaneously on multiple CPU's. Pete From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 17:58:33 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13F5516A402 for ; Sun, 25 Feb 2007 17:58:33 +0000 (UTC) (envelope-from lists@stringsutils.com) Received: from zoraida.natserv.net (p65-147.acedsl.com [66.114.65.147]) by mx1.freebsd.org (Postfix) with ESMTP id C857313C4A7 for ; Sun, 25 Feb 2007 17:58:32 +0000 (UTC) (envelope-from lists@stringsutils.com) Received: from zoraida.natserv.net (localhost.natserv.net [127.0.0.1]) by zoraida.natserv.net (Postfix) with ESMTP id E9D51C31A for ; Sun, 25 Feb 2007 12:58:30 -0500 (EST) Received: by zoraida.natserv.net (Postfix, from userid 58) id 7DD99C318; Sun, 25 Feb 2007 12:58:30 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on zoraida.natserv.net X-Spam-Level: X-Spam-Status: No, score=1.0 required=4.0 tests=RCVD_IN_FIVETENSRC,SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * 1.0 RCVD_IN_FIVETENSRC RBL: Received via a relay in Five Ten block list * [66.114.65.147 listed in blackholes.five-ten-sg.com] Received: from zoraida.natserv.net (zoraida.natserv.net [66.114.65.147]) by zoraida.natserv.net (Postfix) with ESMTP id 1C080C2AF; Sun, 25 Feb 2007 12:58:27 -0500 (EST) References: <0e2001c7574c$26bc15a0$b3db87d4@multiplay.co.uk> <20070224005748.GA25295@xor.obsecurity.org> <45E1C3FC.6040905@he.iki.fi> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Francisco Reyes To: Petri Helenius Date: Sun, 25 Feb 2007 12:58:26 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-performance@freebsd.org, Steven Hartland , Kris Kennaway Subject: Re: FreeBSD Scaling on 6.2-RELEASE? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 17:58:33 -0000 Petri Helenius writes: > The point in threading is that different threads can execute > simultaneously on multiple CPU's. What combination of FreeBSD+Mysql will have multiple threads run by different CPUs? In the few SMP FreeBSD + Mysql setups (mysql 4.X) that I have at work I only see mysql in one cpu as reported by top. From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 18:59:14 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D49D216A404 for ; Sun, 25 Feb 2007 18:59:14 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.freebsd.org (Postfix) with ESMTP id 8ABB413C48E for ; Sun, 25 Feb 2007 18:59:14 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id 2E628359F; Sun, 25 Feb 2007 20:59:13 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+M3Uvn-xMxH; Sun, 25 Feb 2007 20:59:08 +0200 (EET) Received: from [193.64.42.234] (dyn234.helenius.fi [193.64.42.234]) by silver.he.iki.fi (Postfix) with ESMTP; Sun, 25 Feb 2007 20:59:08 +0200 (EET) Message-ID: <45E1DC79.1080005@he.iki.fi> Date: Sun, 25 Feb 2007 20:59:05 +0200 From: Petri Helenius User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Francisco Reyes References: <0e2001c7574c$26bc15a0$b3db87d4@multiplay.co.uk> <20070224005748.GA25295@xor.obsecurity.org> <45E1C3FC.6040905@he.iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, Steven Hartland , Kris Kennaway Subject: Re: FreeBSD Scaling on 6.2-RELEASE? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 18:59:14 -0000 Francisco Reyes wrote: > Petri Helenius writes: > >> The point in threading is that different threads can execute >> simultaneously on multiple CPU's. > > What combination of FreeBSD+Mysql will have multiple threads run by > different CPUs? > > In the few SMP FreeBSD + Mysql setups (mysql 4.X) that I have at work > I only see mysql in one cpu as reported by top. > Since 5.3 and later that should work by default if you install mysql from the ports. Pete From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 19:22:04 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 838E416A403 for ; Sun, 25 Feb 2007 19:22:04 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1095B13C494 for ; Sun, 25 Feb 2007 19:21:59 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.6 required=6.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE,USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003560499.msg for ; Sun, 25 Feb 2007 19:19:39 +0000 Message-ID: <002401c75911$df69fdd0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Francisco Reyes" , "Petri Helenius" References: <0e2001c7574c$26bc15a0$b3db87d4@multiplay.co.uk> <20070224005748.GA25295@xor.obsecurity.org> <45E1C3FC.6040905@he.iki.fi> Date: Sun, 25 Feb 2007 19:19:23 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-performance@freebsd.org X-Spam-Processed: multiplay.co.uk, Sun, 25 Feb 2007 19:19:40 +0000 X-MDAV-Processed: multiplay.co.uk, Sun, 25 Feb 2007 19:19:40 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-performance@freebsd.org, Kris Kennaway Subject: Re: FreeBSD Scaling on 6.2-RELEASE? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 19:22:04 -0000 Francisco Reyes wrote: > What combination of FreeBSD+Mysql will have multiple threads run by > different CPUs? >=20 > In the few SMP FreeBSD + Mysql setups (mysql 4.X) that I have at work > I only see mysql in one cpu as reported by top. I just did the tests highlighted on the thread: Progress on scaling of FreeBSD on 8 CPU systems During that you see mysql using 130+% in top as its being scheduled on more than 1 cpu due it being multi-threaded so this does happen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 19:33:18 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28F2116A403 for ; Sun, 25 Feb 2007 19:33:18 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 11D0513C471 for ; Sun, 25 Feb 2007 19:33:18 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id E0B6F1A4D9B; Sun, 25 Feb 2007 11:33:17 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 353F5524AA; Sun, 25 Feb 2007 14:33:16 -0500 (EST) Date: Sun, 25 Feb 2007 14:33:16 -0500 From: Kris Kennaway To: Francisco Reyes Message-ID: <20070225193316.GD77205@xor.obsecurity.org> References: <0e2001c7574c$26bc15a0$b3db87d4@multiplay.co.uk> <20070224005748.GA25295@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-performance@freebsd.org, Steven Hartland , Kris Kennaway Subject: Re: FreeBSD Scaling on 6.2-RELEASE? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 19:33:18 -0000 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2007 at 11:16:54AM -0500, Francisco Reyes wrote: > Kris Kennaway writes: >=20 > >Actually it will help the DB side, when you have multiple simultaneous > >transactions - that's the point :) >=20 > A little confused. > Does this mean FreeBSD will split the threads into multiple CPUs? Yes, if you're running a modern version of FreeBSD (not 4.x). > Or you meant the DB will do better because the load from other programs= =20 > will be split across the different CPUs? That will also happen. Kris --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF4eR8Wry0BWjoQKURAuKwAKDNDcYcJkZrKx31DoTasWS4pvLCHACgqQwA jnJPXvNGxtLahwQoLsb+ddY= =XyeT -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0-- From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 19:44:35 2007 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4994616A403 for ; Sun, 25 Feb 2007 19:44:35 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id DA37513C4A6 for ; Sun, 25 Feb 2007 19:44:34 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix2-g20.free.fr (Postfix) with ESMTP id 8CDF1B6B5AA for ; Sun, 25 Feb 2007 19:21:00 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id ED7F535B67; Sun, 25 Feb 2007 20:20:47 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id D1A689BE05; Sun, 25 Feb 2007 19:22:39 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id C8F8D405B; Sun, 25 Feb 2007 20:22:39 +0100 (CET) Date: Sun, 25 Feb 2007 20:22:39 +0100 From: Jeremie Le Hen To: Kris Kennaway Message-ID: <20070225192239.GN2479@obiwan.tataz.chchile.org> References: <20070224215508.GA41968@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070224215508.GA41968@xor.obsecurity.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-performance@FreeBSD.org Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 19:44:35 -0000 Hi, Kris, On Sat, Feb 24, 2007 at 04:55:08PM -0500, Kris Kennaway wrote: > Now that the goals of the SMPng project are complete, for the past > year or more several of us have been working hard on profiling FreeBSD > in various multiprocessor workloads, and looking for performance > bottlenecks to be optimized. > > We have recently made significant progress on optimizing for MySQL > running on an 8-core amd64 system. The graph of results may be found > here: > > http://www.freebsd.org/~kris/scaling/scaling.png > > This shows the graph of MySQL transactions/second performed by a > multi-threaded client workload against a local MySQL database with > varying numbers of client threads, with identically configured FreeBSD > and Linux systems on the same machine. I'm really glad to be looking at these results eventually. Thanks to all FreeBSD committers. > The test was run on FreeBSD 7.0, with the latest version of the ULE > 2.0 scheduler, the libthr threading library, and an uncommitted patch > from Jeff Roberson [1] that addresses poor scalability of file > descriptor locking (using a new sleepable mutex primitive); this patch > is responsible for almost all of the performance and scaling > improvements measured. It also includes some other patches (collected > in my kris-contention p4 branch) that have been shown to help > contention in MySQL workloads in the past (including a UNIX domain > socket locking pushdown patch from Robert Watson), but these were > shown to only give small individual contributions, with a cumulative > effect on the order of 5-10%. MySQL uses gettimeofday(2) very often. ISTR it has been stated that MySQL performances could make the most of a system-wide shared page where the current time would be updated regularly by the kernel; gettimeofday(2) could consequentely work without any context switch. Do the patches you're talking about include such a feature already ? Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 19:47:01 2007 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25E8616A400 for ; Sun, 25 Feb 2007 19:47:01 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1247813C428 for ; Sun, 25 Feb 2007 19:47:01 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 722C71A4D97; Sun, 25 Feb 2007 11:47:00 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BCF2C524AA; Sun, 25 Feb 2007 14:46:56 -0500 (EST) Date: Sun, 25 Feb 2007 14:46:56 -0500 From: Kris Kennaway To: Jeremie Le Hen Message-ID: <20070225194656.GA77409@xor.obsecurity.org> References: <20070224215508.GA41968@xor.obsecurity.org> <20070225192239.GN2479@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <20070225192239.GN2479@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-performance@FreeBSD.org, Kris Kennaway Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 19:47:01 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2007 at 08:22:39PM +0100, Jeremie Le Hen wrote: > Hi, Kris, >=20 > On Sat, Feb 24, 2007 at 04:55:08PM -0500, Kris Kennaway wrote: > > Now that the goals of the SMPng project are complete, for the past > > year or more several of us have been working hard on profiling FreeBSD > > in various multiprocessor workloads, and looking for performance > > bottlenecks to be optimized. > >=20 > > We have recently made significant progress on optimizing for MySQL > > running on an 8-core amd64 system. The graph of results may be found > > here: > >=20 > > http://www.freebsd.org/~kris/scaling/scaling.png > >=20 > > This shows the graph of MySQL transactions/second performed by a > > multi-threaded client workload against a local MySQL database with > > varying numbers of client threads, with identically configured FreeBSD > > and Linux systems on the same machine. >=20 > I'm really glad to be looking at these results eventually. Thanks to > all FreeBSD committers. >=20 >=20 > > The test was run on FreeBSD 7.0, with the latest version of the ULE > > 2.0 scheduler, the libthr threading library, and an uncommitted patch > > from Jeff Roberson [1] that addresses poor scalability of file > > descriptor locking (using a new sleepable mutex primitive); this patch > > is responsible for almost all of the performance and scaling > > improvements measured. It also includes some other patches (collected > > in my kris-contention p4 branch) that have been shown to help > > contention in MySQL workloads in the past (including a UNIX domain > > socket locking pushdown patch from Robert Watson), but these were > > shown to only give small individual contributions, with a cumulative > > effect on the order of 5-10%. >=20 > MySQL uses gettimeofday(2) very often. ISTR it has been stated > that MySQL performances could make the most of a system-wide shared > page where the current time would be updated regularly by the kernel; > gettimeofday(2) could consequentely work without any context switch. >=20 > Do the patches you're talking about include such a feature already ? No, but when we tried hacking up gettimeofday last year to see what effect the reduction of syscalls had, it didn't make a lot of difference (at the time there was a theory that this was a major source of the performance difference between freebsd and linux here). It would still be worthwhile to explore implementing such a thing, because it could give some incremental improvements, which are now becoming more interesting to explore for this workload. Kris --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF4eewWry0BWjoQKURAhgWAJ9Z/V/HSHJoBQKmih03DlIS9kxtuwCg8F8P Ix4WaBCnPuBatAF5qAjYkjI= =Juhg -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 20:16:23 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF85D16A403 for ; Sun, 25 Feb 2007 20:16:23 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7966713C47E for ; Sun, 25 Feb 2007 20:16:19 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HLPmq-0003vk-2r for freebsd-performance@freebsd.org; Sun, 25 Feb 2007 21:16:01 +0100 Received: from 89-172-63-188.adsl.net.t-com.hr ([89.172.63.188]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Feb 2007 21:16:00 +0100 Received: from ivoras by 89-172-63-188.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Feb 2007 21:16:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Sun, 25 Feb 2007 21:15:40 +0100 Lines: 32 Message-ID: References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <20070225092947.GA49489@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig947B101F7CFB2E2F49D51659" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-63-188.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) In-Reply-To: <20070225092947.GA49489@xor.obsecurity.org> X-Enigmail-Version: 0.94.1.2 Sender: news Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 20:16:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig947B101F7CFB2E2F49D51659 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > 6.2 and 7.0 CVS sources (which are graphed on Jeff's blog and my > webpage linked there) are unlikely to differ much: as I said, filedesc > locking was key to fixing performance here. I'm sure we'll be > promoting this improvement heavily when 7.0 enters release cycle, to > encourage people to consider upgrading. Sorry, I was very imprecise - I meant 6.2 vs 7-current+patches from that benchmark. --------------enig947B101F7CFB2E2F49D51659 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4e5yldnAQVacBcgRAnRnAKDelXQ2xdpRNlbIbSomPx9noyBkKgCg3lqC AaSCpHdljzhiI9Jf70e2vTs= =vXkJ -----END PGP SIGNATURE----- --------------enig947B101F7CFB2E2F49D51659-- From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 20:21:01 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 607FA16A403 for ; Sun, 25 Feb 2007 20:21:01 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2AC13C46B for ; Sun, 25 Feb 2007 20:21:01 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 2A2751A3C1A; Sun, 25 Feb 2007 12:21:01 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B1A9F517C9; Sun, 25 Feb 2007 15:20:58 -0500 (EST) Date: Sun, 25 Feb 2007 15:20:58 -0500 From: Kris Kennaway To: Ivan Voras Message-ID: <20070225202058.GA77835@xor.obsecurity.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <20070225092947.GA49489@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-performance@freebsd.org Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 20:21:01 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2007 at 09:15:40PM +0100, Ivan Voras wrote: > Kris Kennaway wrote: >=20 > > 6.2 and 7.0 CVS sources (which are graphed on Jeff's blog and my > > webpage linked there) are unlikely to differ much: as I said, filedesc > > locking was key to fixing performance here. I'm sure we'll be > > promoting this improvement heavily when 7.0 enters release cycle, to > > encourage people to consider upgrading. >=20 > Sorry, I was very imprecise - I meant 6.2 vs 7-current+patches from that > benchmark. I'm saying that the 7.0-CVS sources, which are graphed, are unlikely to differ significantly from 6.2-CVS, i.e. they do not show good scaling on this benchmark because of the problems with filedesc locking in CVS. Kris --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF4e+qWry0BWjoQKURArIqAJ95ta5hcrFWNT3l036QjwspLi4KzgCgjP4v 7J5SEOnfQaKQpUOinNVlN68= =Etdo -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 20:22:04 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B49F616A402 for ; Sun, 25 Feb 2007 20:22:04 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC0B13C471 for ; Sun, 25 Feb 2007 20:21:59 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003560658.msg for ; Sun, 25 Feb 2007 20:19:20 +0000 Message-ID: <005d01c7591a$35fa3400$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Francisco Reyes" , "Petri Helenius" References: <0e2001c7574c$26bc15a0$b3db87d4@multiplay.co.uk><20070224005748.GA25295@xor.obsecurity.org><45E1C3FC.6040905@he.iki.fi> Date: Sun, 25 Feb 2007 20:19:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-performance@freebsd.org X-Spam-Processed: multiplay.co.uk, Sun, 25 Feb 2007 20:19:20 +0000 X-MDAV-Processed: multiplay.co.uk, Sun, 25 Feb 2007 20:19:21 +0000 Cc: freebsd-performance@freebsd.org, Kris Kennaway Subject: Re: FreeBSD Scaling on 6.2-RELEASE? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 20:22:04 -0000 Francisco Reyes wrote: > What combination of FreeBSD+Mysql will have multiple threads run by > different CPUs? > > In the few SMP FreeBSD + Mysql setups (mysql 4.X) that I have at work > I only see mysql in one cpu as reported by top. We tested FreeBSD 6.2 and Mysql 5.0 I'd say the main requirement will be modern version of FreeBSD so > 4.x Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 20:26:32 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2F5816A400 for ; Sun, 25 Feb 2007 20:26:32 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.freebsd.org (Postfix) with ESMTP id 3250713C442 for ; Sun, 25 Feb 2007 20:26:31 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id 02022359F; Sun, 25 Feb 2007 22:26:28 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0fB25MyaJEB; Sun, 25 Feb 2007 22:26:22 +0200 (EET) Received: from [193.64.42.234] (dyn234.helenius.fi [193.64.42.234]) by silver.he.iki.fi (Postfix) with ESMTP; Sun, 25 Feb 2007 22:26:22 +0200 (EET) Message-ID: <45E1F0EA.2030605@he.iki.fi> Date: Sun, 25 Feb 2007 22:26:18 +0200 From: Petri Helenius User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Kris Kennaway References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <20070225092947.GA49489@xor.obsecurity.org> <20070225202058.GA77835@xor.obsecurity.org> In-Reply-To: <20070225202058.GA77835@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, Ivan Voras Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 20:26:32 -0000 Kris Kennaway wrote: > > I'm saying that the 7.0-CVS sources, which are graphed, are unlikely > to differ significantly from 6.2-CVS, i.e. they do not show good > scaling on this benchmark because of the problems with filedesc > locking in CVS. > > Could you give a link to the 7.0-CVS graph? Pete From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 20:32:57 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9315416A400 for ; Sun, 25 Feb 2007 20:32:57 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8F113C4A7 for ; Sun, 25 Feb 2007 20:32:57 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id DDAD21A3C1A; Sun, 25 Feb 2007 12:32:56 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4B3635195F; Sun, 25 Feb 2007 15:32:53 -0500 (EST) Date: Sun, 25 Feb 2007 15:32:53 -0500 From: Kris Kennaway To: Petri Helenius Message-ID: <20070225203252.GB77932@xor.obsecurity.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <20070225092947.GA49489@xor.obsecurity.org> <20070225202058.GA77835@xor.obsecurity.org> <45E1F0EA.2030605@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E1F0EA.2030605@he.iki.fi> User-Agent: Mutt/1.4.2.2i Cc: freebsd-performance@freebsd.org, Ivan Voras , Kris Kennaway Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 20:32:57 -0000 On Sun, Feb 25, 2007 at 10:26:18PM +0200, Petri Helenius wrote: > Kris Kennaway wrote: > > > >I'm saying that the 7.0-CVS sources, which are graphed, are unlikely > >to differ significantly from 6.2-CVS, i.e. they do not show good > >scaling on this benchmark because of the problems with filedesc > >locking in CVS. > > > > > Could you give a link to the 7.0-CVS graph? http://obsecurity.dyndns.org/holycrap.png Some of the data is old (e.g. the Linux curve is normalized too high because I was trying to compare it from another machine and the baseline comparison was wrong), but all the FreeBSD data is from the same machine. Kris From owner-freebsd-performance@FreeBSD.ORG Sun Feb 25 20:35:18 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A356516A402 for ; Sun, 25 Feb 2007 20:35:18 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5649313C442 for ; Sun, 25 Feb 2007 20:35:18 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HLQ5I-00075r-OL for freebsd-performance@freebsd.org; Sun, 25 Feb 2007 21:35:04 +0100 Received: from 89-172-63-188.adsl.net.t-com.hr ([89.172.63.188]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Feb 2007 21:35:04 +0100 Received: from ivoras by 89-172-63-188.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Feb 2007 21:35:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Sun, 25 Feb 2007 21:34:45 +0100 Lines: 33 Message-ID: References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <20070225092947.GA49489@xor.obsecurity.org> <20070225202058.GA77835@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0FE54BD3BF5E89608506E882" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-63-188.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) In-Reply-To: <20070225202058.GA77835@xor.obsecurity.org> X-Enigmail-Version: 0.94.1.2 Sender: news Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 20:35:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0FE54BD3BF5E89608506E882 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > I'm saying that the 7.0-CVS sources, which are graphed, are unlikely > to differ significantly from 6.2-CVS, i.e. they do not show good > scaling on this benchmark because of the problems with filedesc > locking in CVS. Ok, got it, but the second question is: where is it? Graph on http://jeffr-tech.livejournal.com/6268.html includes only three FreeBSD-7 configurations, and all show nice scaling. --------------enig0FE54BD3BF5E89608506E882 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4fLlldnAQVacBcgRAmCPAJ9ABVsUiL3ztKVilJkMH4HfQmgRsACgoBIN P4bY0PwnlJ43AV6wT2H8wzY= =rggs -----END PGP SIGNATURE----- --------------enig0FE54BD3BF5E89608506E882-- From owner-freebsd-performance@FreeBSD.ORG Mon Feb 26 00:22:36 2007 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4137716A400; Mon, 26 Feb 2007 00:22:36 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 33A6F13C4B5; Mon, 26 Feb 2007 00:22:36 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 0EFFF1A3C19; Sun, 25 Feb 2007 16:22:36 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7B7F551E81; Sun, 25 Feb 2007 19:22:35 -0500 (EST) Date: Sun, 25 Feb 2007 19:22:35 -0500 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20070226002234.GA80974@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: performance@FreeBSD.org Subject: Anyone interested in improving postgresql scaling? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 00:22:36 -0000 If so, then your task is the following: Make SYSV semaphores less dumb about process wakeups. Currently whenever the semaphore state changes, all processes sleeping on the semaphore are woken, even if we only have released enough resources for one waiting process to claim. i.e. there is a thundering herd wakeup situation which destroys performance at high loads. Fixing this will involve replacing the wakeup() calls with appropriate amounts of wakeup_one(). Kris From owner-freebsd-performance@FreeBSD.ORG Mon Feb 26 18:01:15 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F64E16A406 for ; Mon, 26 Feb 2007 18:01:15 +0000 (UTC) (envelope-from andrew.george.hammond@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2018513C4BA for ; Mon, 26 Feb 2007 18:01:14 +0000 (UTC) (envelope-from andrew.george.hammond@gmail.com) Received: by wr-out-0506.google.com with SMTP id 71so260544wri for ; Mon, 26 Feb 2007 10:01:14 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=llyP4S1gxR1nLKlmmGDC+IJxkxL5eq7g83Gs1x8dxTWhqXXmu9o0lNLxEHmNG0DzG4dxg52J6w2BP1Y6FuLgdSe0HKwUC71+v1fKHKsRNdmmK95V2aHyUGa8tU9xR8gybYHarKNAVW3NJh7U8jM3o70colUsvBQd6lTRQGkf6lM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pvED/VTQr4zTpdWAk5KtJTbaySRbvr4FvPTL+WX3sAVnc68JxvIdREN62USpyNNTKFC6mbd++5kKEFU7a26Zc/JWW4t69wyAgsrXzBtoJRQ1aU4BmB8g6FkSEcop8rxlTIMq98ZaK0OxT6VZZrGuAzWoZNTw+l4Se6WjFPg9Xy4= Received: by 10.115.58.1 with SMTP id l1mr50851wak.1172511405079; Mon, 26 Feb 2007 09:36:45 -0800 (PST) Received: by 10.114.132.17 with HTTP; Mon, 26 Feb 2007 09:36:44 -0800 (PST) Message-ID: <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> Date: Mon, 26 Feb 2007 09:36:44 -0800 From: "Andrew Hammond" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> Cc: freebsd-performance@freebsd.org Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 18:01:15 -0000 On 2/25/07, Ivan Voras wrote: > Kris Kennaway wrote: > > >>>> How does that compare to 6.2-RELEASE performance? > >>>> > >>> Much better. Fixing filedesc locking was key. > >>> > >>> > >> If there is extra cycles on the same hardware, a performance comparison > >> graph would be great. > > > > See the links in my posting ;) > > I think he means graphs between 6-stable and 7-current - it would be > very nice to see those on the same machine, mysql configuration, etc. > (at the very least to clearly show why people should upgrade :) ). Performance is a pretty weak reason to upgrade, unless of course you have a performance problem. The one thing that will really push me to upgrade is bug fixes to stuff that I use where the risk of exposure to the bug outweighs the risk and cost of upgrade. Andrew P.S. I know this is kinda trollish, but I don't understand the interest in MySQL as a load, particularly when there are more interesting loads such as PostgreSQL out there. Would you guys mind graphing the relative performance of PostgreSQL on 6.2-RELEASE and your patched version please? From owner-freebsd-performance@FreeBSD.ORG Mon Feb 26 18:18:29 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D69B916A404 for ; Mon, 26 Feb 2007 18:18:29 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 87ACA13C461 for ; Mon, 26 Feb 2007 18:18:29 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HLkQT-0005QN-5B for freebsd-performance@freebsd.org; Mon, 26 Feb 2007 19:18:17 +0100 Received: from 89-172-37-177.adsl.net.t-com.hr ([89.172.37.177]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Feb 2007 19:18:17 +0100 Received: from ivoras by 89-172-37-177.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Feb 2007 19:18:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Mon, 26 Feb 2007 19:17:51 +0100 Lines: 33 Message-ID: References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAC15AED34735C1899A1CA83A" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-37-177.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) In-Reply-To: <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> X-Enigmail-Version: 0.94.1.2 Sender: news Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 18:18:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAC15AED34735C1899A1CA83A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andrew Hammond wrote: > Performance is a pretty weak reason to upgrade, unless of course you > have a performance problem.=20 > P.S. I know this is kinda trollish, but I don't understand the > interest in MySQL as a load,=20 I agree in general, but MySQL performance is very exposed as an advocacy issue - it has traditionally been the source of statements like "FreeBSD's threading implementation is weak/bad/broken". --------------enigAC15AED34735C1899A1CA83A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4yRZldnAQVacBcgRAmJTAKDARxVKyfDymy6rtoYv7FNRmTZtvQCguMit JkF8L3Wxwn3AASsgc878/bQ= =8CwN -----END PGP SIGNATURE----- --------------enigAC15AED34735C1899A1CA83A-- From owner-freebsd-performance@FreeBSD.ORG Mon Feb 26 19:35:54 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F9F616A401 for ; Mon, 26 Feb 2007 19:35:54 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5B1BE13C48D for ; Mon, 26 Feb 2007 19:35:54 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 232661A3C1A; Mon, 26 Feb 2007 11:35:54 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A45935138A; Mon, 26 Feb 2007 14:35:52 -0500 (EST) Date: Mon, 26 Feb 2007 14:35:52 -0500 From: Kris Kennaway To: Andrew Hammond Message-ID: <20070226193552.GA14088@xor.obsecurity.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-performance@freebsd.org, Ivan Voras Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 19:35:54 -0000 On Mon, Feb 26, 2007 at 09:36:44AM -0800, Andrew Hammond wrote: > Would you guys mind > graphing the relative performance of PostgreSQL on 6.2-RELEASE and > your patched version please? postgresql currently performs worse than mysql on SMP freeBSD systems for the reason I posted yesterday (thundering herd wakeups in sysv semaphoes). Once someone fixes that I'll be happy to retest. Kris From owner-freebsd-performance@FreeBSD.ORG Mon Feb 26 19:37:23 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 796FA16A401 for ; Mon, 26 Feb 2007 19:37:23 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 011EC13C474 for ; Mon, 26 Feb 2007 19:37:22 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003564423.msg for ; Mon, 26 Feb 2007 19:32:33 +0000 Message-ID: <046f01c759dc$d60a60b0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Andrew Hammond" , "Ivan Voras" References: <20070224215508.GA41968@xor.obsecurity.org><45E13410.7020505@he.iki.fi><20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi><20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> Date: Mon, 26 Feb 2007 19:32:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-performance@freebsd.org X-Spam-Processed: multiplay.co.uk, Mon, 26 Feb 2007 19:32:35 +0000 X-MDAV-Processed: multiplay.co.uk, Mon, 26 Feb 2007 19:32:35 +0000 Cc: freebsd-performance@freebsd.org Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 19:37:23 -0000 Andrew Hammond wrote: > Performance is a pretty weak reason to upgrade, unless of course you > have a performance problem. The one thing that will really push me to > upgrade is bug fixes to stuff that I use where the risk of exposure to > the bug outweighs the risk and cost of upgrade. This may be the case for you but for people who are seeing poor performance scaling this would be a very welcome upgrade. > P.S. I know this is kinda trollish, but I don't understand the > interest in MySQL as a load, particularly when there are more > interesting loads such as PostgreSQL out there. Would you guys mind > graphing the relative performance of PostgreSQL on 6.2-RELEASE and > your patched version please? What makes PostgreSQL more interesting? Because you use it perhaps? I would hesitate a guess that Mysql is a very common workload under FreeBSD likely more so than PostgreSQL and as such that would be a very good reason for it to have particular interest and hence focus as a good starting point. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-performance@FreeBSD.ORG Mon Feb 26 20:52:26 2007 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EB3B16A401; Mon, 26 Feb 2007 20:52:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1302A13C49D; Mon, 26 Feb 2007 20:52:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 33E0147E56; Mon, 26 Feb 2007 15:52:25 -0500 (EST) Date: Mon, 26 Feb 2007 20:52:25 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20070226204916.C56223@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@FreeBSD.org Subject: HEADS UP: UNIX domain socket locking changes merged to CVS HEAD X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 20:52:26 -0000 Dear all, After on-and-off development since 2005, I've now merged the UNIX domain socket locking patch. Special thanks to Kris Kennaway who has been providing stability testing, performance testing, and general support and feedback for this project since inception. Please let me know if you experience any problems with UNIX domain sockets -- these changes will affect applications that consume UNIX domain sockets directly, like MySQL and Postfix, as well as consumers of POSIX fifos, which are implemented using UNIX domain sockets in-kernel. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 26 Feb 2007 20:47:52 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/sys unpcb.h src/sys/kern uipc_usrreq.c rwatson 2007-02-26 20:47:52 UTC FreeBSD src repository Modified files: sys/sys unpcb.h sys/kern uipc_usrreq.c Log: Revise locking strategy used for UNIX domain sockets in order to improve concurrency: - Add per-unpcb mutexes protecting unpcb connection state, fields, etc. - Replace global UNP mutex with a global UNP rwlock, which will protect the UNIX domain socket connection topology, v_socket, and be acquired exclusively before acquiring more than per-unpcb at a time in order to avoid lock order issues. In performance measurements involving MySQL, this change has little or no overhead on UP (+/- 1%), but leads to a significant (5%-30%) improvement in multi-processor measurements using the sysbench and supersmack benchmarks. Much testing by: kris Approved by: re (kensmith) Revision Changes Path 1.197 +468 -222 src/sys/kern/uipc_usrreq.c 1.22 +1 -0 src/sys/sys/unpcb.h From owner-freebsd-performance@FreeBSD.ORG Mon Feb 26 22:40:44 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E621B16A401 for ; Mon, 26 Feb 2007 22:40:44 +0000 (UTC) (envelope-from paul@pathiakis.com) Received: from mail2.eagleinvsys.com (mail2.eagleinvsys.com [151.203.101.53]) by mx1.freebsd.org (Postfix) with ESMTP id 9F30A13C47E for ; Mon, 26 Feb 2007 22:40:44 +0000 (UTC) (envelope-from paul@pathiakis.com) Received: from [10.40.1.102] ([10.40.1.102]) by mail2.eagleinvsys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Feb 2007 17:19:19 -0500 From: Paul Pathiakis Organization: Atlantis Services To: freebsd-performance@freebsd.org Date: Mon, 26 Feb 2007 17:18:45 -0500 User-Agent: KMail/1.9.5 References: <20070226204916.C56223@fledge.watson.org> In-Reply-To: <20070226204916.C56223@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702261718.45499.paul@pathiakis.com> X-OriginalArrivalTime: 26 Feb 2007 22:19:19.0829 (UTC) FILETIME=[2902CC50:01C759F4] Subject: Re: HEADS UP: UNIX domain socket locking changes merged to CVS HEAD X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 22:40:45 -0000 Thank you, Robert. P. On Monday 26 February 2007 15:52, Robert Watson wrote: > Dear all, > > After on-and-off development since 2005, I've now merged the UNIX domain > socket locking patch. Special thanks to Kris Kennaway who has been > providing stability testing, performance testing, and general support and > feedback for this project since inception. > > Please let me know if you experience any problems with UNIX domain sockets > -- these changes will affect applications that consume UNIX domain sockets > directly, like MySQL and Postfix, as well as consumers of POSIX fifos, > which are implemented using UNIX domain sockets in-kernel. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > From owner-freebsd-performance@FreeBSD.ORG Mon Feb 26 22:40:45 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90F6216A402 for ; Mon, 26 Feb 2007 22:40:45 +0000 (UTC) (envelope-from paul@pathiakis.com) Received: from mail2.eagleinvsys.com (mail2.eagleinvsys.com [151.203.101.53]) by mx1.freebsd.org (Postfix) with ESMTP id 44DF313C494 for ; Mon, 26 Feb 2007 22:40:45 +0000 (UTC) (envelope-from paul@pathiakis.com) Received: from [10.40.1.102] ([10.40.1.102]) by mail2.eagleinvsys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Feb 2007 17:18:08 -0500 From: Paul Pathiakis Organization: Atlantis Services To: freebsd-performance@freebsd.org Date: Mon, 26 Feb 2007 17:17:33 -0500 User-Agent: KMail/1.9.5 References: <20070224215508.GA41968@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <046f01c759dc$d60a60b0$b3db87d4@multiplay.co.uk> In-Reply-To: <046f01c759dc$d60a60b0$b3db87d4@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702261717.33325.paul@pathiakis.com> X-OriginalArrivalTime: 26 Feb 2007 22:18:08.0079 (UTC) FILETIME=[FE3E9DF0:01C759F3] Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 22:40:45 -0000 > > What makes PostgreSQL more interesting? Because you use it perhaps? > I would hesitate a guess that Mysql is a very common workload > under FreeBSD likely more so than PostgreSQL and as such that > would be a very good reason for it to have particular interest > and hence focus as a good starting point. > > Steve > I'm not trying to start a flame war, I'm just trying to give my take on "perception" here. PostgreSQL is developed on FreeBSD and they've always had a close relationship by means of FreeBSD being the "platform of choice". PostgreSQL is considered a "real" database. When you look at commercial databases, there tend to be two large market shares: Oracle and DB2. Oracle has moved into the realm of clustered access database with multiple path writing into the DB and it can scale to be quite large. PostgreSQL has a large installed base. SUN Microsystems is now supporting it. It's free. It has advanced features like clustering. It scales to be quite large. MySQL has been the "white elephant in the middle of the room" for a while and then it became the thing for the Linux community to point at to "prove" inferiority. MySQL is on the order of the small to medium db. Easy to configure, easy to tune. Similar to MS SQL, it's widely used and scales to a certain level (so far, however, this new benchmarking may show it's not MySQL that's the issue.) Please don't jump on this mail, it's just a "perception" letter. There's no facts in it and I freely admit that. It's a "touchy/feely" thing in the OSS community. I've helped a few companies replace heavy read Oracle DBs with PostgreSQL. They love not paying money to Larry & Co. P. From owner-freebsd-performance@FreeBSD.ORG Wed Feb 28 09:54:57 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B05D16A404 for ; Wed, 28 Feb 2007 09:54:57 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from mx.isc.org (mx.isc.org [204.152.184.167]) by mx1.freebsd.org (Postfix) with ESMTP id 1DCA613C461 for ; Wed, 28 Feb 2007 09:54:57 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 3D09A1140B1 for ; Wed, 28 Feb 2007 09:09:05 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from [204.152.189.103] (tardis.vpn.isc.org [204.152.189.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id B0D3CE60DC; Wed, 28 Feb 2007 09:09:04 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Message-ID: <45E54619.7000503@isc.org> Date: Wed, 28 Feb 2007 01:06:33 -0800 From: Peter Losher Organization: ISC User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC3FC749B53B6451FA1521876" Subject: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 09:54:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC3FC749B53B6451FA1521876 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > I agree in general, but MySQL performance is very exposed as an advocac= y > issue - it has traditionally been the source of statements like > "FreeBSD's threading implementation is weak/bad/broken". And these days ISC can't consciously recommend FreeBSD for use on high-traffic DNS servers because UDP performance has (frankly) gone downhill since 5.x. We recently put a stock Fedora Core 6 and a stock FreeBSD 6.2 on the same HW (HP ProLiant DL320 G5 Dual Core Xeons w/ 16GB RAM) and running BIND 9.4.0 and a well known ccTLD zone that we slammed a query stream to. On a single threaded BIND, there was a 20% advantage to Linux, on a multi threaded build, Linux trounced FreeBSD (39k to 89k queries/sec) There's also been other analysis done by Marcelo Amarai @ Registro.br that was posted to freebsd-net back last September. http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011748.html= I know there have been some discussion between some of the FreeBSD folks and my colleague Mark Andrews about improving BIND's performance on FreeBSD. Is there anything coming down the pipeline that will help stem this tide in 7.x? -Peter --=20 Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" --------------enigC3FC749B53B6451FA1521876 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF5UYZPtVx9OgEjQgRAqYUAKCWji6zaaJUzpaINu/QAvdKNLZdvQCeMDtn cbRVxBld43TQ1W52TwWYej8= =dfvL -----END PGP SIGNATURE----- --------------enigC3FC749B53B6451FA1521876-- From owner-freebsd-performance@FreeBSD.ORG Wed Feb 28 13:44:42 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F48316A402 for ; Wed, 28 Feb 2007 13:44:42 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 30A2A13C442 for ; Wed, 28 Feb 2007 13:44:42 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l1SD81Hv086270; Wed, 28 Feb 2007 07:08:10 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45E57EB5.4070703@freebsd.org> Date: Wed, 28 Feb 2007 07:08:05 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: Peter Losher References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <45E54619.7000503@isc.org> In-Reply-To: <45E54619.7000503@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2679/Wed Feb 28 05:58:10 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-performance@freebsd.org Subject: Re: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 13:44:42 -0000 On 02/28/07 03:06, Peter Losher wrote: > Ivan Voras wrote: > >> I agree in general, but MySQL performance is very exposed as an advocacy >> issue - it has traditionally been the source of statements like >> "FreeBSD's threading implementation is weak/bad/broken". > > And these days ISC can't consciously recommend FreeBSD for use on > high-traffic DNS servers because UDP performance has (frankly) gone > downhill since 5.x. > > We recently put a stock Fedora Core 6 and a stock FreeBSD 6.2 on the > same HW (HP ProLiant DL320 G5 Dual Core Xeons w/ 16GB RAM) and running > BIND 9.4.0 and a well known ccTLD zone that we slammed a query stream > to. On a single threaded BIND, there was a 20% advantage to Linux, on a > multi threaded build, Linux trounced FreeBSD (39k to 89k queries/sec) > > There's also been other analysis done by Marcelo Amarai @ Registro.br > that was posted to freebsd-net back last September. > > http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011748.html > > I know there have been some discussion between some of the FreeBSD folks > and my colleague Mark Andrews about improving BIND's performance on > FreeBSD. Is there anything coming down the pipeline that will help stem > this tide in 7.x? > > -Peter I wonder if the recent work done for mysql would help here or not? I'm guessing the socket work would most likely help, but that's merely a guess. BIND is an important piece of infrastructure code, and because it comes with FreeBSD base OS, maybe it should next on the performance hit list? Eric From owner-freebsd-performance@FreeBSD.ORG Wed Feb 28 14:08:54 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9783916A403 for ; Wed, 28 Feb 2007 14:08:54 +0000 (UTC) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (mail.qubeconnect.com [202.190.74.25]) by mx1.freebsd.org (Postfix) with SMTP id C14B213C4A6 for ; Wed, 28 Feb 2007 14:08:53 +0000 (UTC) (envelope-from dinesh@alphaque.com) Received: (qmail 21419 invoked by uid 0); 28 Feb 2007 13:41:43 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.190.74.25) by lucifer.net-gw.com with SMTP; 28 Feb 2007 13:41:43 -0000 Received: from prophet.alphaque.com (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.8/8.13.4) with ESMTP id l1SDg1eg021870 for ; Wed, 28 Feb 2007 21:42:01 +0800 (MYT) (envelope-from dinesh@alphaque.com) Date: Wed, 28 Feb 2007 21:42:00 +0800 From: Dinesh Nair To: freebsd-performance@freebsd.org Message-ID: <20070228214200.60cc9b7a@prophet.alphaque.com> In-Reply-To: <45E54619.7000503@isc.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <45E54619.7000503@isc.org> Organization: Alphaque. Anytime. Anywhere X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 14:08:54 -0000 On Wed, 28 Feb 2007 01:06:33 -0800, Peter Losher wrote: > Ivan Voras wrote: > > > I agree in general, but MySQL performance is very exposed as an > > advocacy issue - it has traditionally been the source of statements > > like "FreeBSD's threading implementation is weak/bad/broken". > > And these days ISC can't consciously recommend FreeBSD for use on > high-traffic DNS servers because UDP performance has (frankly) gone > downhill since 5.x. > [..snipped..] > http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011748.html if UDP performance in 6.x and 7.x has dropped, this could even affect voip applications/servers such as asterisk when run on FreeBSD. most all use RTP for media traffic and RTP is nearly always UDP generating up to 50 packets per second per call per direction. 14,000+ packets per second is only about 140 calls. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.openmalaysiablog.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-performance@FreeBSD.ORG Wed Feb 28 14:18:29 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFDC716A401 for ; Wed, 28 Feb 2007 14:18:29 +0000 (UTC) (envelope-from kreios@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 77F9413C49D for ; Wed, 28 Feb 2007 14:18:27 +0000 (UTC) (envelope-from kreios@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so128906wxc for ; Wed, 28 Feb 2007 06:18:22 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=FqbUYbmGk1n5jYAyf1Mysl2YhwZMbk006ZZjduHdLriwkC1GGtbRZaeSp0dRkslBvxEjFUea5psmhvHJ4sxSrLLbD8yp7wUnwO921uo75y0sCWUynltHoxtKsFmcehyynPUwNQQ8T+5L5+4Oz5rdCabmZoyeehY0SqGHfIPkaok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=PDVUyFiOMt2WScSKbxX+Ps8c8nlHVKo8tgqjzabdbLfkzVCaA7R+mktNzm6ZOUawYATmZYkXZHT1fG7YG/9jrNCapgmd4oeToaPxC45G84hOF24WRq1+ELcZdKThrh6aYuOz7Qo2Sk1z7Hyug8S6aHYasn5mK9rfI/tj3+ROovQ= Received: by 10.90.99.20 with SMTP id w20mr342053agb.1172670557814; Wed, 28 Feb 2007 05:49:17 -0800 (PST) Received: from ?10.0.1.2? ( [71.113.231.44]) by mx.google.com with ESMTP id 7sm785134wrl.2007.02.28.05.49.16; Wed, 28 Feb 2007 05:49:17 -0800 (PST) In-Reply-To: <45E54619.7000503@isc.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <45E54619.7000503@isc.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A286106-52A9-40D0-903B-D3746B671759@gmail.com> Content-Transfer-Encoding: 7bit From: Dave Date: Wed, 28 Feb 2007 07:49:14 -0600 To: Peter Losher X-Mailer: Apple Mail (2.752.2) Cc: freebsd-performance@freebsd.org Subject: Re: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 14:18:29 -0000 On Feb 28, 2007, at 3:06 AM, Peter Losher wrote: > Ivan Voras wrote: > >> I agree in general, but MySQL performance is very exposed as an >> advocacy >> issue - it has traditionally been the source of statements like >> "FreeBSD's threading implementation is weak/bad/broken". > > And these days ISC can't consciously recommend FreeBSD for use on > high-traffic DNS servers because UDP performance has (frankly) gone > downhill since 5.x. > > We recently put a stock Fedora Core 6 and a stock FreeBSD 6.2 on the > same HW (HP ProLiant DL320 G5 Dual Core Xeons w/ 16GB RAM) and running > BIND 9.4.0 and a well known ccTLD zone that we slammed a query stream > to. On a single threaded BIND, there was a 20% advantage to Linux, > on a > multi threaded build, Linux trounced FreeBSD (39k to 89k queries/sec) > > There's also been other analysis done by Marcelo Amarai @ Registro.br > that was posted to freebsd-net back last September. > > http://lists.freebsd.org/pipermail/freebsd-net/2006-September/ > 011748.html > > I know there have been some discussion between some of the FreeBSD > folks > and my colleague Mark Andrews about improving BIND's performance on > FreeBSD. Is there anything coming down the pipeline that will help > stem > this tide in 7.x? I also did some testing and came up with different numbers: http://lists.freebsd.org/pipermail/freebsd-performance/2006-October/ 002267.html I still need to go back and check 9.4.0 and vary the zone size. My zone was very small. If you have any suggestions, let me know. My goal in testing was to see what was the best configuration for bind and how it compared to Linux. -- Dave From owner-freebsd-performance@FreeBSD.ORG Wed Feb 28 15:52:15 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D3F716A404 for ; Wed, 28 Feb 2007 15:52:15 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0260113C48D for ; Wed, 28 Feb 2007 15:52:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1SERXkj064758; Wed, 28 Feb 2007 09:27:33 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id l1SERX4i076677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 09:27:33 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200702281427.l1SERX4i076677@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Feb 2007 09:25:31 -0500 To: Peter Losher , freebsd-performance@freebsd.org From: Mike Tancsa In-Reply-To: <45E54619.7000503@isc.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <45E54619.7000503@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 15:52:15 -0000 At 04:06 AM 2/28/2007, Peter Losher wrote: >We recently put a stock Fedora Core 6 and a stock FreeBSD 6.2 on the >same HW (HP ProLiant DL320 G5 Dual Core Xeons w/ 16GB RAM) and running Is that using PAE or AMD64 ? ---Mike From owner-freebsd-performance@FreeBSD.ORG Wed Feb 28 19:39:51 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F9AD16A403 for ; Wed, 28 Feb 2007 19:39:51 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from mx.isc.org (mx.isc.org [204.152.184.167]) by mx1.freebsd.org (Postfix) with ESMTP id 1C78C13C4B2 for ; Wed, 28 Feb 2007 19:39:51 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id E86331140AD for ; Wed, 28 Feb 2007 19:39:50 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from [10.0.0.3] (adsl-69-107-108-92.dsl.pltn13.pacbell.net [69.107.108.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id CDE38E60DC for ; Wed, 28 Feb 2007 19:39:50 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Message-ID: <45E5DA86.9030107@isc.org> Date: Wed, 28 Feb 2007 11:39:50 -0800 From: Peter Losher User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <45E54619.7000503@isc.org> <200702281427.l1SERX4i076677@lava.sentex.ca> In-Reply-To: <200702281427.l1SERX4i076677@lava.sentex.ca> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig55C4ED9E65C240F84726BD59" Subject: Re: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 19:39:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig55C4ED9E65C240F84726BD59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mike Tancsa wrote: > Is that using PAE or AMD64 ? amd64 in both cases (Linux and FreeBSD) -Peter --=20 Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" --------------enig55C4ED9E65C240F84726BD59 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFF5dqGPtVx9OgEjQgRAtyOAJsEFExA/yJ7tMK6U98BjunM8ufatACgr6yz Win1nPyF0EtxuTO+lXn92cw= =AdRj -----END PGP SIGNATURE----- --------------enig55C4ED9E65C240F84726BD59-- From owner-freebsd-performance@FreeBSD.ORG Thu Mar 1 09:45:46 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C5A316A400 for ; Thu, 1 Mar 2007 09:45:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3381613C428 for ; Thu, 1 Mar 2007 09:45:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 062984854D; Thu, 1 Mar 2007 04:23:27 -0500 (EST) Date: Thu, 1 Mar 2007 09:23:26 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Losher In-Reply-To: <45E54619.7000503@isc.org> Message-ID: <20070301091218.H13593@fledge.watson.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <45E54619.7000503@isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-performance@freebsd.org Subject: Re: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 09:45:46 -0000 On Wed, 28 Feb 2007, Peter Losher wrote: > Ivan Voras wrote: > >> I agree in general, but MySQL performance is very exposed as an advocacy >> issue - it has traditionally been the source of statements like "FreeBSD's >> threading implementation is weak/bad/broken". > > And these days ISC can't consciously recommend FreeBSD for use on > high-traffic DNS servers because UDP performance has (frankly) gone downhill > since 5.x. > > We recently put a stock Fedora Core 6 and a stock FreeBSD 6.2 on the same HW > (HP ProLiant DL320 G5 Dual Core Xeons w/ 16GB RAM) and running BIND 9.4.0 > and a well known ccTLD zone that we slammed a query stream to. On a single > threaded BIND, there was a 20% advantage to Linux, on a multi threaded > build, Linux trounced FreeBSD (39k to 89k queries/sec) > > There's also been other analysis done by Marcelo Amarai @ Registro.br that > was posted to freebsd-net back last September. > > http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011748.html > > I know there have been some discussion between some of the FreeBSD folks and > my colleague Mark Andrews about improving BIND's performance on FreeBSD. > Is there anything coming down the pipeline that will help stem this tide in > 7.x? Yes -- we have a specific optimization in 7.x to improve the performance of highly contended multi-threaded send on a single UNIX domain socket as a direct result of those conversations with ISC folk. It's in the MFC pipeline, but not something I felt comfortable merging for 6.2 without a bit more experience with it in the field. If you're interested in testing (and specifically, measuring) this patch in a high performance DNS test environment, that would be wonderful -- in the original e-mail thread I wa unable to successfully solicit testing of the patch. Likewise, when I requested access to test query streams from ISC, I was told those couldn't be shared. I've had a recent request for an MFC, and hope to have a chance to update and test the RELENG_6 sosend_dgram() patch in the next few days and will post it to this mailing list when it's ready. Unfortunately, this month is scary-travel-month so my oppoprtunities to do back-port testing myself in the next two weeks are limited. What would be extremely helpful is to have someone willing to own the "BIND9 benchmarking" item as Kris has done for MySQL, who could provide regular support in testing updated FreeBSD versions and patches against a specific reproduceable workload, and participate in a continuing dialog on measuring and improving performance. It's those sorts of dialogs that are invaluable in improving performance, as frequently FreeBSD developers have limited access to real-world workloads other than the ones in their own environments, and have less familiarity with the application architecture. Kris's long-term work in measuring MySQL performance and working with developers to test and improve patches is why FreeBSD 7.x (with patches) now performs four times better than Linux under load. The first step here would be to perform a performance baseline measurement with head-of-tree 7.x (debugging features in user-space and kernel disabled first, threading library switched to libthr) and compare it with 6.2-RELEASE. This would let us know if the current generation of optimization work is effective in improving BIND9 traffic with your configuration and workload. We can then apply a series of the current out-of-tree optimizing patches for threading and scheduling and see if those help. (The above applies to any workload people are concerned about, BTW: what we need right now is people willing to take ownership of benchmarking and engage with developers in measuring change over time). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-performance@FreeBSD.ORG Thu Mar 1 09:55:07 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96EA316A400 for ; Thu, 1 Mar 2007 09:55:07 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 2D72C13C461 for ; Thu, 1 Mar 2007 09:55:07 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so815646nfc for ; Thu, 01 Mar 2007 01:55:06 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V7GYCdBQuvnTQvdsX4URIsGaHOfu1y70FHGenBLogvn2jUBdZKwAmPJk7Gj1T+uNedFxqVWXulikLhvF0TcEIoejisgdpp79Uxv+4iDAKgg8nI4IIoxApe1htZF0lPXt47RJAQbUruuMKpIoCP7oHHElBe7ewF/STcOxcfvtKew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o1UuU6lDW9eu+OdIUumNMxy3Yf1p0VGgLRyNdly5HJqSuuUIFVr1QF5ztD/dY21AbXzCOiUFZijWD1qalWKHnD8QfOBQhUm8DGuBrQCfv/a5k2ioqY6iatCMRSg7NvBgyNgNYXP4VmWIhdPwRTp2s73VsDgsW1W12W7Dl7RT/Gg= Received: by 10.82.154.2 with SMTP id b2mr508782bue.1172741299532; Thu, 01 Mar 2007 01:28:19 -0800 (PST) Received: by 10.82.151.15 with HTTP; Thu, 1 Mar 2007 01:28:19 -0800 (PST) Message-ID: Date: Thu, 1 Mar 2007 01:28:19 -0800 From: "Kip Macy" To: "Peter Losher" In-Reply-To: <45E54619.7000503@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <45E54619.7000503@isc.org> Cc: freebsd-performance@freebsd.org Subject: Re: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 09:55:07 -0000 > We recently put a stock Fedora Core 6 and a stock FreeBSD 6.2 on the > same HW (HP ProLiant DL320 G5 Dual Core Xeons w/ 16GB RAM) and running > BIND 9.4.0 and a well known ccTLD zone that we slammed a query stream > to. On a single threaded BIND, there was a 20% advantage to Linux, on a > multi threaded build, Linux trounced FreeBSD (39k to 89k queries/sec) > > There's also been other analysis done by Marcelo Amarai @ Registro.br > that was posted to freebsd-net back last September. > > http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011748.html> I have a couple of dual Woodcrests running back-to-back over multiple 10GigE cards that I'd like to do performance testing with. Did you use the same testing methodology as Marcelo? If not can you go into more detail on your setup and how to reproduce? -Kip From owner-freebsd-performance@FreeBSD.ORG Thu Mar 1 10:13:03 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2570A16A418 for ; Thu, 1 Mar 2007 10:13:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C89CC13C4E8 for ; Thu, 1 Mar 2007 10:13:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0619347433; Thu, 1 Mar 2007 05:12:58 -0500 (EST) Date: Thu, 1 Mar 2007 10:12:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: Message-ID: <20070301100535.Y13593@fledge.watson.org> References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <45E54619.7000503@isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-performance@freebsd.org, Peter Losher Subject: Re: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 10:13:03 -0000 On Thu, 1 Mar 2007, Kip Macy wrote: >> We recently put a stock Fedora Core 6 and a stock FreeBSD 6.2 on the same >> HW (HP ProLiant DL320 G5 Dual Core Xeons w/ 16GB RAM) and running BIND >> 9.4.0 and a well known ccTLD zone that we slammed a query stream to. On a >> single threaded BIND, there was a 20% advantage to Linux, on a multi >> threaded build, Linux trounced FreeBSD (39k to 89k queries/sec) >> >> There's also been other analysis done by Marcelo Amarai @ Registro.br that >> was posted to freebsd-net back last September. >> >> http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011748.html> > > I have a couple of dual Woodcrests running back-to-back over multiple 10GigE > cards that I'd like to do performance testing with. Did you use the same > testing methodology as Marcelo? If not can you go into more detail on your > setup and how to reproduce? BIND9 includes a tool called "queryperf" that can be used to generate DNS query workloads against a DNS server and characterize the results. You'll need to provide zone(s) and a list of queries to perform. It's not imported in our contrib tree, but can be found in the port. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-performance@FreeBSD.ORG Thu Mar 1 11:30:45 2007 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D6AB16A402 for ; Thu, 1 Mar 2007 11:30:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C768213C442 for ; Thu, 1 Mar 2007 11:30:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 420CA47475; Thu, 1 Mar 2007 06:30:44 -0500 (EST) Date: Thu, 1 Mar 2007 11:30:44 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Lars Erik Gullerud In-Reply-To: <20070218185837.R16107@electra.nolink.net> Message-ID: <20070301111957.S13593@fledge.watson.org> References: <20070216223258.S16107@electra.nolink.net> <20070216221505.D73842@fledge.watson.org> <20070218185837.R16107@electra.nolink.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-429716139-1172748644=:13593" Cc: performance@FreeBSD.org Subject: Re: MFC of UDP socket enhancement for BIND? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 11:30:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-429716139-1172748644=:13593 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sun, 18 Feb 2007, Lars Erik Gullerud wrote: > On Fri, 16 Feb 2007, Robert Watson wrote: > >> I can certainly investigate doing this -- since 6.2 is safely out the door >> it's a good time to do so. I'll follow up by e-mail in a few days -- would >> it be possible for you to help with testing? > > We would of course be most happy to test any patches you come up with, and > run performance benchmarks on our systems. It turns out this change comes in two parts: (1) In the first part, the structure of the socket send routing, sosend(), is simplified by breaking out the code that copies data from user space from the code that transmits via the protocol. (2) In the second part, a version of sosend() specific to datagram protocols (where the socket send buffer isn't ever used) is added. I'm going to attach two patches against RELENG_6 from today -- the first performs only the first step (sosend_copyin.diff), and the second performs both (sosend_dgram.diff) (so will have to be applied against a fresh version of uipc_socket.c as opposed to the patched version). The first change requires heavy stability testing, and the second requires both performance and stability testing. Any assistance from you in helping to make this a reliable MFC would be much appreciated. For reference, the sosend_copyin.diff applies these changes: src/sys/kern/uipc_socket.c:1.253, 1.254, 1.255 The sosend_dgram.diff patch incrementally also applies these changes on top of sosend_copyin.diff: src/sys/kern/uipc_socket.c:1.256 src/sys/netinet/udp_usrreq.c:1.188 I've CC'd the performance list as there is a relevant thread going on there right now, and other people might also be interested in reviewing and testing these changes. The short description is that this eliminates a large number of socket buffer interactions in the UDP send path--one of the effects is to avoid locking the socket buffer for an extended period, as it's largely unused in the datagram transmit path. Per the commit comments, this idea was suggested by Jinmei Tatsuya at ISC as a result of their performance analysis; this change has been in 7-CURRENT since May of last year and has seen some bug fixes but no substantial changes in that time, so has been moderately burned in. Robert N M Watson Computer Laboratory University of Cambridge --0-429716139-1172748644=:13593 Content-Type: TEXT/plain; charset=US-ASCII; name=sosend_copyin.diff Content-Transfer-Encoding: BASE64 Content-ID: <20070301113044.E13593@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=sosend_copyin.diff SW5kZXg6IGtlcm4vdWlwY19zb2NrZXQuYw0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9rZXJuL3VpcGNf c29ja2V0LmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjI0Mi4yLjgNCmRp ZmYgLXUgLXIxLjI0Mi4yLjggdWlwY19zb2NrZXQuYw0KLS0tIGtlcm4vdWlw Y19zb2NrZXQuYwkzIEZlYiAyMDA3IDA0OjAxOjIyIC0wMDAwCTEuMjQyLjIu OA0KKysrIGtlcm4vdWlwY19zb2NrZXQuYwkxIE1hciAyMDA3IDExOjE4OjM1 IC0wMDAwDQpAQCAtNTg0LDcgKzU4NCwxNDkgQEANCiAJcmV0dXJuIChlcnJv cik7DQogfQ0KIA0KKyNpZmRlZiBaRVJPX0NPUFlfU09DS0VUUw0KK3N0cnVj dCBzb196ZXJvY29weV9zdGF0c3sNCisJaW50IHNpemVfb2s7DQorCWludCBh bGlnbl9vazsNCisJaW50IGZvdW5kX2lmcDsNCit9Ow0KK3N0cnVjdCBzb196 ZXJvY29weV9zdGF0cyBzb196ZXJvY3Bfc3RhdHMgPSB7MCwwLDB9Ow0KKyNp bmNsdWRlIDxuZXRpbmV0L2luLmg+DQorI2luY2x1ZGUgPG5ldC9yb3V0ZS5o Pg0KKyNpbmNsdWRlIDxuZXRpbmV0L2luX3BjYi5oPg0KKyNpbmNsdWRlIDx2 bS92bS5oPg0KKyNpbmNsdWRlIDx2bS92bV9wYWdlLmg+DQorI2luY2x1ZGUg PHZtL3ZtX29iamVjdC5oPg0KKyNlbmRpZiAvKlpFUk9fQ09QWV9TT0NLRVRT Ki8NCisNCisvKg0KKyAqIHNvc2VuZF9jb3B5aW4oKSBhY2NlcHRzIGEgdWlv IGFuZCBwcmVwYXJlcyBhbiBtYnVmIGNoYWluIGhvbGRpbmcgcGFydCBvcg0K KyAqIGFsbCBvZiB0aGUgZGF0YSByZWZlcmVuY2VkIGJ5IHRoZSB1aW8uICBJ ZiBkZXNpcmVkLCBpdCB1c2VzIHplcm8tY29weS4NCisgKiAqc3BhY2Ugd2ls bCBiZSB1cGRhdGVkIHRvIHJlZmxlY3QgZGF0YSBjb3BpZWQgaW4uDQorICoN CisgKiBOQjogSWYgYXRvbWljIEkvTyBpcyByZXF1ZXN0ZWQsIHRoZSBjYWxs ZXIgbXVzdCBhbHJlYWR5IGhhdmUgY2hlY2tlZCB0aGF0DQorICogc3BhY2Ug Y2FuIGhvbGQgcmVzaWQgYnl0ZXMuDQorICoNCisgKiBOQjogSW4gdGhlIGV2 ZW50IG9mIGFuIGVycm9yLCB0aGUgY2FsbGVyIG1heSBuZWVkIHRvIGZyZWUg dGhlIHBhcnRpYWwNCisgKiBjaGFpbiBwb2ludGVkIHRvIGJ5ICptcHAuICBU aGUgY29udGVudHMgb2YgYm90aCAqdWlvIGFuZCAqc3BhY2UgbWF5IGJlDQor ICogbW9kaWZpZWQgZXZlbiBpbiB0aGUgY2FzZSBvZiBhbiBlcnJvci4NCisg Ki8NCitzdGF0aWMgaW50DQorc29zZW5kX2NvcHlpbihzdHJ1Y3QgdWlvICp1 aW8sIHN0cnVjdCBtYnVmICoqcmV0bXAsIGludCBhdG9taWMsIGxvbmcgKnNw YWNlLA0KKyAgICBpbnQgZmxhZ3MpDQorew0KKwlzdHJ1Y3QgbWJ1ZiAqbSwg KiptcCwgKnRvcDsNCisJbG9uZyBsZW4sIHJlc2lkOw0KKwlpbnQgZXJyb3I7 DQorI2lmZGVmIFpFUk9fQ09QWV9TT0NLRVRTDQorCWludCBjb3dfc2VuZDsN CisjZW5kaWYNCisNCisJKnJldG1wID0gdG9wID0gTlVMTDsNCisJbXAgPSAm dG9wOw0KKwlsZW4gPSAwOw0KKwlyZXNpZCA9IHVpby0+dWlvX3Jlc2lkOw0K KwllcnJvciA9IDA7DQorCWRvIHsNCisjaWZkZWYgWkVST19DT1BZX1NPQ0tF VFMNCisJCWNvd19zZW5kID0gMDsNCisjZW5kaWYgLyogWkVST19DT1BZX1NP Q0tFVFMgKi8NCisJCWlmIChyZXNpZCA+PSBNSU5DTFNJWkUpIHsNCisjaWZk ZWYgWkVST19DT1BZX1NPQ0tFVFMNCisJCQlpZiAodG9wID09IE5VTEwpIHsN CisJCQkJTUdFVEhEUihtLCBNX1RSWVdBSVQsIE1UX0RBVEEpOw0KKwkJCQlp ZiAobSA9PSBOVUxMKSB7DQorCQkJCQllcnJvciA9IEVOT0JVRlM7DQorCQkJ CQlnb3RvIG91dDsNCisJCQkJfQ0KKwkJCQltLT5tX3BrdGhkci5sZW4gPSAw Ow0KKwkJCQltLT5tX3BrdGhkci5yY3ZpZiA9IE5VTEw7IA0KKwkJCX0gZWxz ZSB7DQorCQkJCU1HRVQobSwgTV9UUllXQUlULCBNVF9EQVRBKTsNCisJCQkJ aWYgKG0gPT0gTlVMTCkgew0KKwkJCQkJZXJyb3IgPSBFTk9CVUZTOw0KKwkJ CQkJZ290byBvdXQ7DQorCQkJCX0NCisJCQl9DQorCQkJaWYgKHNvX3plcm9f Y29weV9zZW5kICYmDQorCQkJICAgIHJlc2lkPj1QQUdFX1NJWkUgJiYNCisJ CQkgICAgKnNwYWNlPj1QQUdFX1NJWkUgJiYNCisJCQkgICAgdWlvLT51aW9f aW92LT5pb3ZfbGVuPj1QQUdFX1NJWkUpIHsNCisJCQkJc29femVyb2NwX3N0 YXRzLnNpemVfb2srKzsNCisJCQkJc29femVyb2NwX3N0YXRzLmFsaWduX29r Kys7DQorCQkJCWNvd19zZW5kID0gc29jb3dfc2V0dXAobSwgdWlvKTsNCisJ CQkJbGVuID0gY293X3NlbmQ7DQorCQkJfQ0KKwkJCWlmICghY293X3NlbmQp IHsNCisJCQkJTUNMR0VUKG0sIE1fVFJZV0FJVCk7DQorCQkJCWlmICgobS0+ bV9mbGFncyAmIE1fRVhUKSA9PSAwKSB7DQorCQkJCQltX2ZyZWUobSk7DQor CQkJCQltID0gTlVMTDsNCisJCQkJfSBlbHNlIHsNCisJCQkJCWxlbiA9IG1p bihtaW4oTUNMQllURVMsIHJlc2lkKSwNCisJCQkJCSAgICAqc3BhY2UpOw0K KwkJCQl9DQorCQkJfQ0KKyNlbHNlIC8qIFpFUk9fQ09QWV9TT0NLRVRTICov DQorCQkJaWYgKHRvcCA9PSBOVUxMKSB7DQorCQkJCW0gPSBtX2dldGNsKE1f VFJZV0FJVCwgTVRfREFUQSwgTV9QS1RIRFIpOw0KKwkJCQltLT5tX3BrdGhk ci5sZW4gPSAwOw0KKwkJCQltLT5tX3BrdGhkci5yY3ZpZiA9IE5VTEw7DQor CQkJfSBlbHNlDQorCQkJCW0gPSBtX2dldGNsKE1fVFJZV0FJVCwgTVRfREFU QSwgMCk7DQorCQkJbGVuID0gbWluKG1pbihNQ0xCWVRFUywgcmVzaWQpLCAq c3BhY2UpOw0KKyNlbmRpZiAvKiBaRVJPX0NPUFlfU09DS0VUUyAqLw0KKwkJ fSBlbHNlIHsNCisJCQlpZiAodG9wID09IE5VTEwpIHsNCisJCQkJbSA9IG1f Z2V0aGRyKE1fVFJZV0FJVCwgTVRfREFUQSk7DQorCQkJCW0tPm1fcGt0aGRy LmxlbiA9IDA7DQorCQkJCW0tPm1fcGt0aGRyLnJjdmlmID0gTlVMTDsNCisN CisJCQkJbGVuID0gbWluKG1pbihNSExFTiwgcmVzaWQpLCAqc3BhY2UpOw0K KwkJCQkvKg0KKwkJCQkgKiBGb3IgZGF0YWdyYW0gcHJvdG9jb2xzLCBsZWF2 ZSByb29tDQorCQkJCSAqIGZvciBwcm90b2NvbCBoZWFkZXJzIGluIGZpcnN0 IG1idWYuDQorCQkJCSAqLw0KKwkJCQlpZiAoYXRvbWljICYmIG0gJiYgbGVu IDwgTUhMRU4pDQorCQkJCQlNSF9BTElHTihtLCBsZW4pOw0KKwkJCX0gZWxz ZSB7DQorCQkJCW0gPSBtX2dldChNX1RSWVdBSVQsIE1UX0RBVEEpOw0KKwkJ CQlsZW4gPSBtaW4obWluKE1MRU4sIHJlc2lkKSwgKnNwYWNlKTsNCisJCQl9 DQorCQl9DQorCQlpZiAobSA9PSBOVUxMKSB7DQorCQkJZXJyb3IgPSBFTk9C VUZTOw0KKwkJCWdvdG8gb3V0Ow0KKwkJfQ0KKw0KKwkJKnNwYWNlIC09IGxl bjsNCisjaWZkZWYgWkVST19DT1BZX1NPQ0tFVFMNCisJCWlmIChjb3dfc2Vu ZCkNCisJCQllcnJvciA9IDA7DQorCQllbHNlDQorI2VuZGlmIC8qIFpFUk9f Q09QWV9TT0NLRVRTICovDQorCQllcnJvciA9IHVpb21vdmUobXRvZChtLCB2 b2lkICopLCAoaW50KWxlbiwgdWlvKTsNCisJCXJlc2lkID0gdWlvLT51aW9f cmVzaWQ7DQorCQltLT5tX2xlbiA9IGxlbjsNCisJCSptcCA9IG07DQorCQl0 b3AtPm1fcGt0aGRyLmxlbiArPSBsZW47DQorCQlpZiAoZXJyb3IpDQorCQkJ Z290byBvdXQ7DQorCQltcCA9ICZtLT5tX25leHQ7DQorCQlpZiAocmVzaWQg PD0gMCkgew0KKwkJCWlmIChmbGFncyAmIE1TR19FT1IpDQorCQkJCXRvcC0+ bV9mbGFncyB8PSBNX0VPUjsNCisJCQlicmVhazsNCisJCX0NCisJfSB3aGls ZSAoKnNwYWNlID4gMCAmJiBhdG9taWMpOw0KK291dDoNCisJKnJldG1wID0g dG9wOw0KKwlyZXR1cm4gKGVycm9yKTsNCit9DQorDQogI2RlZmluZQlTQkxP Q0tXQUlUKGYpCSgoKGYpICYgTVNHX0RPTlRXQUlUKSA/IE1fTk9XQUlUIDog TV9XQUlUT0spDQorI2RlZmluZQlzbmRlcnIoZXJybm8pCXsgZXJyb3IgPSAo ZXJybm8pOyBnb3RvIHJlbGVhc2U7IH0NCisNCiAvKg0KICAqIFNlbmQgb24g YSBzb2NrZXQuDQogICogSWYgc2VuZCBtdXN0IGdvIGFsbCBhdCBvbmNlIGFu ZCBtZXNzYWdlIGlzIGxhcmdlciB0aGFuDQpAQCAtNjAzLDIxICs3NDUsNiBA QA0KICAqIERhdGEgYW5kIGNvbnRyb2wgYnVmZmVycyBhcmUgZnJlZWQgb24g cmV0dXJuLg0KICAqLw0KIA0KLSNpZmRlZiBaRVJPX0NPUFlfU09DS0VUUw0K LXN0cnVjdCBzb196ZXJvY29weV9zdGF0c3sNCi0JaW50IHNpemVfb2s7DQot CWludCBhbGlnbl9vazsNCi0JaW50IGZvdW5kX2lmcDsNCi19Ow0KLXN0cnVj dCBzb196ZXJvY29weV9zdGF0cyBzb196ZXJvY3Bfc3RhdHMgPSB7MCwwLDB9 Ow0KLSNpbmNsdWRlIDxuZXRpbmV0L2luLmg+DQotI2luY2x1ZGUgPG5ldC9y b3V0ZS5oPg0KLSNpbmNsdWRlIDxuZXRpbmV0L2luX3BjYi5oPg0KLSNpbmNs dWRlIDx2bS92bS5oPg0KLSNpbmNsdWRlIDx2bS92bV9wYWdlLmg+DQotI2lu Y2x1ZGUgPHZtL3ZtX29iamVjdC5oPg0KLSNlbmRpZiAvKlpFUk9fQ09QWV9T T0NLRVRTKi8NCi0NCiBpbnQNCiBzb3NlbmQoc28sIGFkZHIsIHVpbywgdG9w LCBjb250cm9sLCBmbGFncywgdGQpDQogCXN0cnVjdCBzb2NrZXQgKnNvOw0K QEAgLTYyOCwxNCArNzU1LDkgQEANCiAJaW50IGZsYWdzOw0KIAlzdHJ1Y3Qg dGhyZWFkICp0ZDsNCiB7DQotCXN0cnVjdCBtYnVmICoqbXA7DQotCXN0cnVj dCBtYnVmICptOw0KLQlsb25nIHNwYWNlLCBsZW4gPSAwLCByZXNpZDsNCisJ bG9uZyBzcGFjZSwgcmVzaWQ7DQogCWludCBjbGVuID0gMCwgZXJyb3IsIGRv bnRyb3V0ZTsNCiAJaW50IGF0b21pYyA9IHNvc2VuZGFsbGF0b25jZShzbykg fHwgdG9wOw0KLSNpZmRlZiBaRVJPX0NPUFlfU09DS0VUUw0KLQlpbnQgY293 X3NlbmQ7DQotI2VuZGlmIC8qIFpFUk9fQ09QWV9TT0NLRVRTICovDQogDQog CWlmICh1aW8gIT0gTlVMTCkNCiAJCXJlc2lkID0gdWlvLT51aW9fcmVzaWQ7 DQpAQCAtNjYzLDcgKzc4NSw2IEBADQogCQl0ZC0+dGRfcHJvYy0+cF9zdGF0 cy0+cF9ydS5ydV9tc2dzbmQrKzsNCiAJaWYgKGNvbnRyb2wgIT0gTlVMTCkN CiAJCWNsZW4gPSBjb250cm9sLT5tX2xlbjsNCi0jZGVmaW5lCXNuZGVycihl cnJubykJeyBlcnJvciA9IChlcnJubyk7IGdvdG8gcmVsZWFzZTsgfQ0KIA0K IAlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0KIHJlc3RhcnQ6DQpAQCAt NzEzLDE1MyArODM0LDYxIEBADQogCQkJZ290byByZXN0YXJ0Ow0KIAkJfQ0K IAkJU09DS0JVRl9VTkxPQ0soJnNvLT5zb19zbmQpOw0KLQkJbXAgPSAmdG9w Ow0KIAkJc3BhY2UgLT0gY2xlbjsNCiAJCWRvIHsNCi0JCSAgICBpZiAodWlv ID09IE5VTEwpIHsNCi0JCQkvKg0KLQkJCSAqIERhdGEgaXMgcHJlcGFja2Fn ZWQgaW4gInRvcCIuDQotCQkJICovDQotCQkJcmVzaWQgPSAwOw0KLQkJCWlm IChmbGFncyAmIE1TR19FT1IpDQotCQkJCXRvcC0+bV9mbGFncyB8PSBNX0VP UjsNCi0JCSAgICB9IGVsc2UgZG8gew0KLSNpZmRlZiBaRVJPX0NPUFlfU09D S0VUUw0KLQkJCWNvd19zZW5kID0gMDsNCi0jZW5kaWYgLyogWkVST19DT1BZ X1NPQ0tFVFMgKi8NCi0JCQlpZiAocmVzaWQgPj0gTUlOQ0xTSVpFKSB7DQot I2lmZGVmIFpFUk9fQ09QWV9TT0NLRVRTDQotCQkJCWlmICh0b3AgPT0gTlVM TCkgew0KLQkJCQkJTUdFVEhEUihtLCBNX1RSWVdBSVQsIE1UX0RBVEEpOw0K LQkJCQkJaWYgKG0gPT0gTlVMTCkgew0KLQkJCQkJCWVycm9yID0gRU5PQlVG UzsNCi0JCQkJCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0KLQkJCQkJ CWdvdG8gcmVsZWFzZTsNCi0JCQkJCX0NCi0JCQkJCW0tPm1fcGt0aGRyLmxl biA9IDA7DQotCQkJCQltLT5tX3BrdGhkci5yY3ZpZiA9IE5VTEw7IA0KLQkJ CQl9IGVsc2Ugew0KLQkJCQkJTUdFVChtLCBNX1RSWVdBSVQsIE1UX0RBVEEp Ow0KLQkJCQkJaWYgKG0gPT0gTlVMTCkgew0KLQkJCQkJCWVycm9yID0gRU5P QlVGUzsNCi0JCQkJCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0KLQkJ CQkJCWdvdG8gcmVsZWFzZTsNCi0JCQkJCX0NCi0JCQkJfQ0KLQkJCQlpZiAo c29femVyb19jb3B5X3NlbmQgJiYNCi0JCQkJICAgIHJlc2lkPj1QQUdFX1NJ WkUgJiYNCi0JCQkJICAgIHNwYWNlPj1QQUdFX1NJWkUgJiYNCi0JCQkJICAg IHVpby0+dWlvX2lvdi0+aW92X2xlbj49UEFHRV9TSVpFKSB7DQotCQkJCQlz b196ZXJvY3Bfc3RhdHMuc2l6ZV9vaysrOw0KLQkJCQkJc29femVyb2NwX3N0 YXRzLmFsaWduX29rKys7DQotCQkJCQljb3dfc2VuZCA9IHNvY293X3NldHVw KG0sIHVpbyk7DQotCQkJCQlsZW4gPSBjb3dfc2VuZDsNCi0JCQkJfQ0KLQkJ CQlpZiAoIWNvd19zZW5kKSB7DQotCQkJCQlNQ0xHRVQobSwgTV9UUllXQUlU KTsNCi0JCQkJCWlmICgobS0+bV9mbGFncyAmIE1fRVhUKSA9PSAwKSB7DQot CQkJCQkJbV9mcmVlKG0pOw0KLQkJCQkJCW0gPSBOVUxMOw0KLQkJCQkJfSBl bHNlIHsNCi0JCQkJCQlsZW4gPSBtaW4obWluKE1DTEJZVEVTLCByZXNpZCks IHNwYWNlKTsNCi0JCQkJCX0NCi0JCQkJfQ0KLSNlbHNlIC8qIFpFUk9fQ09Q WV9TT0NLRVRTICovDQotCQkJCWlmICh0b3AgPT0gTlVMTCkgew0KLQkJCQkJ bSA9IG1fZ2V0Y2woTV9UUllXQUlULCBNVF9EQVRBLCBNX1BLVEhEUik7DQot CQkJCQltLT5tX3BrdGhkci5sZW4gPSAwOw0KLQkJCQkJbS0+bV9wa3RoZHIu cmN2aWYgPSBOVUxMOw0KLQkJCQl9IGVsc2UNCi0JCQkJCW0gPSBtX2dldGNs KE1fVFJZV0FJVCwgTVRfREFUQSwgMCk7DQotCQkJCWxlbiA9IG1pbihtaW4o TUNMQllURVMsIHJlc2lkKSwgc3BhY2UpOw0KLSNlbmRpZiAvKiBaRVJPX0NP UFlfU09DS0VUUyAqLw0KKwkJCWlmICh1aW8gPT0gTlVMTCkgew0KKwkJCQly ZXNpZCA9IDA7DQorCQkJCWlmIChmbGFncyAmIE1TR19FT1IpDQorCQkJCQl0 b3AtPm1fZmxhZ3MgfD0gTV9FT1I7DQogCQkJfSBlbHNlIHsNCi0JCQkJaWYg KHRvcCA9PSBOVUxMKSB7DQotCQkJCQltID0gbV9nZXRoZHIoTV9UUllXQUlU LCBNVF9EQVRBKTsNCi0JCQkJCW0tPm1fcGt0aGRyLmxlbiA9IDA7DQotCQkJ CQltLT5tX3BrdGhkci5yY3ZpZiA9IE5VTEw7DQotDQotCQkJCQlsZW4gPSBt aW4obWluKE1ITEVOLCByZXNpZCksIHNwYWNlKTsNCi0JCQkJCS8qDQotCQkJ CQkgKiBGb3IgZGF0YWdyYW0gcHJvdG9jb2xzLCBsZWF2ZSByb29tDQotCQkJ CQkgKiBmb3IgcHJvdG9jb2wgaGVhZGVycyBpbiBmaXJzdCBtYnVmLg0KLQkJ CQkJICovDQotCQkJCQlpZiAoYXRvbWljICYmIG0gJiYgbGVuIDwgTUhMRU4p DQotCQkJCQkJTUhfQUxJR04obSwgbGVuKTsNCi0JCQkJfSBlbHNlIHsNCi0J CQkJCW0gPSBtX2dldChNX1RSWVdBSVQsIE1UX0RBVEEpOw0KLQkJCQkJbGVu ID0gbWluKG1pbihNTEVOLCByZXNpZCksIHNwYWNlKTsNCisJCQkJZXJyb3Ig PSBzb3NlbmRfY29weWluKHVpbywgJnRvcCwgYXRvbWljLA0KKwkJCQkgICAg JnNwYWNlLCBmbGFncyk7DQorCQkJCWlmIChlcnJvciAhPSAwKSB7DQorCQkJ CQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0KKwkJCQkJZ290byByZWxl YXNlOw0KIAkJCQl9DQorCQkJCXJlc2lkID0gdWlvLT51aW9fcmVzaWQ7DQog CQkJfQ0KLQkJCWlmIChtID09IE5VTEwpIHsNCi0JCQkJZXJyb3IgPSBFTk9C VUZTOw0KLQkJCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0KLQkJCQln b3RvIHJlbGVhc2U7DQorCQkJaWYgKGRvbnRyb3V0ZSkgew0KKwkJCQlTT0NL X0xPQ0soc28pOw0KKwkJCQlzby0+c29fb3B0aW9ucyB8PSBTT19ET05UUk9V VEU7DQorCQkJCVNPQ0tfVU5MT0NLKHNvKTsNCiAJCQl9DQotDQotCQkJc3Bh Y2UgLT0gbGVuOw0KLSNpZmRlZiBaRVJPX0NPUFlfU09DS0VUUw0KLQkJCWlm IChjb3dfc2VuZCkNCi0JCQkJZXJyb3IgPSAwOw0KLQkJCWVsc2UNCi0jZW5k aWYgLyogWkVST19DT1BZX1NPQ0tFVFMgKi8NCi0JCQllcnJvciA9IHVpb21v dmUobXRvZChtLCB2b2lkICopLCAoaW50KWxlbiwgdWlvKTsNCi0JCQlyZXNp ZCA9IHVpby0+dWlvX3Jlc2lkOw0KLQkJCW0tPm1fbGVuID0gbGVuOw0KLQkJ CSptcCA9IG07DQotCQkJdG9wLT5tX3BrdGhkci5sZW4gKz0gbGVuOw0KLQkJ CWlmIChlcnJvcikgew0KLQkJCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQp Ow0KLQkJCQlnb3RvIHJlbGVhc2U7DQotCQkJfQ0KLQkJCW1wID0gJm0tPm1f bmV4dDsNCi0JCQlpZiAocmVzaWQgPD0gMCkgew0KLQkJCQlpZiAoZmxhZ3Mg JiBNU0dfRU9SKQ0KLQkJCQkJdG9wLT5tX2ZsYWdzIHw9IE1fRU9SOw0KLQkJ CQlicmVhazsNCi0JCQl9DQotCQkgICAgfSB3aGlsZSAoc3BhY2UgPiAwICYm IGF0b21pYyk7DQotCQkgICAgaWYgKGRvbnRyb3V0ZSkgew0KLQkJCSAgICBT T0NLX0xPQ0soc28pOw0KLQkJCSAgICBzby0+c29fb3B0aW9ucyB8PSBTT19E T05UUk9VVEU7DQotCQkJICAgIFNPQ0tfVU5MT0NLKHNvKTsNCi0JCSAgICB9 DQotCQkgICAgLyoNCi0JCSAgICAgKiBYWFggYWxsIHRoZSBTQlNfQ0FOVFNF TkRNT1JFIGNoZWNrcyBwcmV2aW91c2x5DQotCQkgICAgICogZG9uZSBjb3Vs ZCBiZSBvdXQgb2YgZGF0ZS4gIFdlIGNvdWxkIGhhdmUgcmVjaWV2ZWQNCi0J CSAgICAgKiBhIHJlc2V0IHBhY2tldCBpbiBhbiBpbnRlcnJ1cHQgb3IgbWF5 YmUgd2Ugc2xlcHQNCi0JCSAgICAgKiB3aGlsZSBkb2luZyBwYWdlIGZhdWx0 cyBpbiB1aW9tb3ZlKCkgZXRjLiBXZSBjb3VsZA0KLQkJICAgICAqIHByb2Jh Ymx5IHJlY2hlY2sgYWdhaW4gaW5zaWRlIHRoZSBsb2NraW5nIHByb3RlY3Rp b24NCi0JCSAgICAgKiBoZXJlLCBidXQgdGhlcmUgYXJlIHByb2JhYmx5IG90 aGVyIHBsYWNlcyB0aGF0IHRoaXMNCi0JCSAgICAgKiBhbHNvIGhhcHBlbnMu ICBXZSBtdXN0IHJldGhpbmsgdGhpcy4NCi0JCSAgICAgKi8NCi0JCSAgICBl cnJvciA9ICgqc28tPnNvX3Byb3RvLT5wcl91c3JyZXFzLT5wcnVfc2VuZCko c28sDQotCQkJKGZsYWdzICYgTVNHX09PQikgPyBQUlVTX09PQiA6DQorCQkJ LyoNCisJCQkgKiBYWFggYWxsIHRoZSBTQlNfQ0FOVFNFTkRNT1JFIGNoZWNr cyBwcmV2aW91c2x5DQorCQkJICogZG9uZSBjb3VsZCBiZSBvdXQgb2YgZGF0 ZS4gIFdlIGNvdWxkIGhhdmUgcmVjaWV2ZWQNCisJCQkgKiBhIHJlc2V0IHBh Y2tldCBpbiBhbiBpbnRlcnJ1cHQgb3IgbWF5YmUgd2Ugc2xlcHQNCisJCQkg KiB3aGlsZSBkb2luZyBwYWdlIGZhdWx0cyBpbiB1aW9tb3ZlKCkgZXRjLiBX ZSBjb3VsZA0KKwkJCSAqIHByb2JhYmx5IHJlY2hlY2sgYWdhaW4gaW5zaWRl IHRoZSBsb2NraW5nIHByb3RlY3Rpb24NCisJCQkgKiBoZXJlLCBidXQgdGhl cmUgYXJlIHByb2JhYmx5IG90aGVyIHBsYWNlcyB0aGF0IHRoaXMNCisJCQkg KiBhbHNvIGhhcHBlbnMuICBXZSBtdXN0IHJldGhpbmsgdGhpcy4NCisJCQkg Ki8NCisJCQllcnJvciA9ICgqc28tPnNvX3Byb3RvLT5wcl91c3JyZXFzLT5w cnVfc2VuZCkoc28sDQorCQkJICAgIChmbGFncyAmIE1TR19PT0IpID8gUFJV U19PT0IgOg0KIAkJCS8qDQogCQkJICogSWYgdGhlIHVzZXIgc2V0IE1TR19F T0YsIHRoZSBwcm90b2NvbA0KIAkJCSAqIHVuZGVyc3RhbmRzIHRoaXMgZmxh ZyBhbmQgbm90aGluZyBsZWZ0IHRvDQogCQkJICogc2VuZCB0aGVuIHVzZSBQ UlVfU0VORF9FT0YgaW5zdGVhZCBvZiBQUlVfU0VORC4NCiAJCQkgKi8NCi0J CQkoKGZsYWdzICYgTVNHX0VPRikgJiYNCi0JCQkgKHNvLT5zb19wcm90by0+ cHJfZmxhZ3MgJiBQUl9JTVBMT1BDTCkgJiYNCi0JCQkgKHJlc2lkIDw9IDAp KSA/DQorCQkJICAgICgoZmxhZ3MgJiBNU0dfRU9GKSAmJg0KKwkJCSAgICAg KHNvLT5zb19wcm90by0+cHJfZmxhZ3MgJiBQUl9JTVBMT1BDTCkgJiYNCisJ CQkgICAgIChyZXNpZCA8PSAwKSkgPw0KIAkJCQlQUlVTX0VPRiA6DQogCQkJ LyogSWYgdGhlcmUgaXMgbW9yZSB0byBzZW5kIHNldCBQUlVTX01PUkVUT0NP TUUgKi8NCi0JCQkocmVzaWQgPiAwICYmIHNwYWNlID4gMCkgPyBQUlVTX01P UkVUT0NPTUUgOiAwLA0KLQkJCXRvcCwgYWRkciwgY29udHJvbCwgdGQpOw0K LQkJICAgIGlmIChkb250cm91dGUpIHsNCi0JCQkgICAgU09DS19MT0NLKHNv KTsNCi0JCQkgICAgc28tPnNvX29wdGlvbnMgJj0gflNPX0RPTlRST1VURTsN Ci0JCQkgICAgU09DS19VTkxPQ0soc28pOw0KLQkJICAgIH0NCi0JCSAgICBj bGVuID0gMDsNCi0JCSAgICBjb250cm9sID0gTlVMTDsNCi0JCSAgICB0b3Ag PSBOVUxMOw0KLQkJICAgIG1wID0gJnRvcDsNCi0JCSAgICBpZiAoZXJyb3Ip IHsNCi0JCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0KLQkJCWdvdG8g cmVsZWFzZTsNCi0JCSAgICB9DQorCQkJICAgIChyZXNpZCA+IDAgJiYgc3Bh Y2UgPiAwKSA/IFBSVVNfTU9SRVRPQ09NRSA6IDAsDQorCQkJICAgIHRvcCwg YWRkciwgY29udHJvbCwgdGQpOw0KKwkJCWlmIChkb250cm91dGUpIHsNCisJ CQkJU09DS19MT0NLKHNvKTsNCisJCQkJc28tPnNvX29wdGlvbnMgJj0gflNP X0RPTlRST1VURTsNCisJCQkJU09DS19VTkxPQ0soc28pOw0KKwkJCX0NCisJ CQljbGVuID0gMDsNCisJCQljb250cm9sID0gTlVMTDsNCisJCQl0b3AgPSBO VUxMOw0KKwkJCWlmIChlcnJvcikgew0KKwkJCQlTT0NLQlVGX0xPQ0soJnNv LT5zb19zbmQpOw0KKwkJCQlnb3RvIHJlbGVhc2U7DQorCQkJfQ0KIAkJfSB3 aGlsZSAocmVzaWQgJiYgc3BhY2UgPiAwKTsNCiAJCVNPQ0tCVUZfTE9DSygm c28tPnNvX3NuZCk7DQogCX0gd2hpbGUgKHJlc2lkKTsNCg== --0-429716139-1172748644=:13593 Content-Type: TEXT/plain; charset=US-ASCII; name=sosend_dgram.diff Content-Transfer-Encoding: BASE64 Content-ID: <20070301113044.G13593@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=sosend_dgram.diff SW5kZXg6IGtlcm4vdWlwY19zb2NrZXQuYw0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9rZXJuL3VpcGNf c29ja2V0LmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjI0Mi4yLjgNCmRp ZmYgLXUgLXIxLjI0Mi4yLjggdWlwY19zb2NrZXQuYw0KLS0tIGtlcm4vdWlw Y19zb2NrZXQuYwkzIEZlYiAyMDA3IDA0OjAxOjIyIC0wMDAwCTEuMjQyLjIu OA0KKysrIGtlcm4vdWlwY19zb2NrZXQuYwkxIE1hciAyMDA3IDExOjI3OjEx IC0wMDAwDQpAQCAtNTg0LDcgKzU4NCwzMDEgQEANCiAJcmV0dXJuIChlcnJv cik7DQogfQ0KIA0KKyNpZmRlZiBaRVJPX0NPUFlfU09DS0VUUw0KK3N0cnVj dCBzb196ZXJvY29weV9zdGF0c3sNCisJaW50IHNpemVfb2s7DQorCWludCBh bGlnbl9vazsNCisJaW50IGZvdW5kX2lmcDsNCit9Ow0KK3N0cnVjdCBzb196 ZXJvY29weV9zdGF0cyBzb196ZXJvY3Bfc3RhdHMgPSB7MCwwLDB9Ow0KKyNp bmNsdWRlIDxuZXRpbmV0L2luLmg+DQorI2luY2x1ZGUgPG5ldC9yb3V0ZS5o Pg0KKyNpbmNsdWRlIDxuZXRpbmV0L2luX3BjYi5oPg0KKyNpbmNsdWRlIDx2 bS92bS5oPg0KKyNpbmNsdWRlIDx2bS92bV9wYWdlLmg+DQorI2luY2x1ZGUg PHZtL3ZtX29iamVjdC5oPg0KKyNlbmRpZiAvKlpFUk9fQ09QWV9TT0NLRVRT Ki8NCisNCisvKg0KKyAqIHNvc2VuZF9jb3B5aW4oKSBhY2NlcHRzIGEgdWlv IGFuZCBwcmVwYXJlcyBhbiBtYnVmIGNoYWluIGhvbGRpbmcgcGFydCBvcg0K KyAqIGFsbCBvZiB0aGUgZGF0YSByZWZlcmVuY2VkIGJ5IHRoZSB1aW8uICBJ ZiBkZXNpcmVkLCBpdCB1c2VzIHplcm8tY29weS4NCisgKiAqc3BhY2Ugd2ls bCBiZSB1cGRhdGVkIHRvIHJlZmxlY3QgZGF0YSBjb3BpZWQgaW4uDQorICoN CisgKiBOQjogSWYgYXRvbWljIEkvTyBpcyByZXF1ZXN0ZWQsIHRoZSBjYWxs ZXIgbXVzdCBhbHJlYWR5IGhhdmUgY2hlY2tlZCB0aGF0DQorICogc3BhY2Ug Y2FuIGhvbGQgcmVzaWQgYnl0ZXMuDQorICoNCisgKiBOQjogSW4gdGhlIGV2 ZW50IG9mIGFuIGVycm9yLCB0aGUgY2FsbGVyIG1heSBuZWVkIHRvIGZyZWUg dGhlIHBhcnRpYWwNCisgKiBjaGFpbiBwb2ludGVkIHRvIGJ5ICptcHAuICBU aGUgY29udGVudHMgb2YgYm90aCAqdWlvIGFuZCAqc3BhY2UgbWF5IGJlDQor ICogbW9kaWZpZWQgZXZlbiBpbiB0aGUgY2FzZSBvZiBhbiBlcnJvci4NCisg Ki8NCitzdGF0aWMgaW50DQorc29zZW5kX2NvcHlpbihzdHJ1Y3QgdWlvICp1 aW8sIHN0cnVjdCBtYnVmICoqcmV0bXAsIGludCBhdG9taWMsIGxvbmcgKnNw YWNlLA0KKyAgICBpbnQgZmxhZ3MpDQorew0KKwlzdHJ1Y3QgbWJ1ZiAqbSwg KiptcCwgKnRvcDsNCisJbG9uZyBsZW4sIHJlc2lkOw0KKwlpbnQgZXJyb3I7 DQorI2lmZGVmIFpFUk9fQ09QWV9TT0NLRVRTDQorCWludCBjb3dfc2VuZDsN CisjZW5kaWYNCisNCisJKnJldG1wID0gdG9wID0gTlVMTDsNCisJbXAgPSAm dG9wOw0KKwlsZW4gPSAwOw0KKwlyZXNpZCA9IHVpby0+dWlvX3Jlc2lkOw0K KwllcnJvciA9IDA7DQorCWRvIHsNCisjaWZkZWYgWkVST19DT1BZX1NPQ0tF VFMNCisJCWNvd19zZW5kID0gMDsNCisjZW5kaWYgLyogWkVST19DT1BZX1NP Q0tFVFMgKi8NCisJCWlmIChyZXNpZCA+PSBNSU5DTFNJWkUpIHsNCisjaWZk ZWYgWkVST19DT1BZX1NPQ0tFVFMNCisJCQlpZiAodG9wID09IE5VTEwpIHsN CisJCQkJTUdFVEhEUihtLCBNX1RSWVdBSVQsIE1UX0RBVEEpOw0KKwkJCQlp ZiAobSA9PSBOVUxMKSB7DQorCQkJCQllcnJvciA9IEVOT0JVRlM7DQorCQkJ CQlnb3RvIG91dDsNCisJCQkJfQ0KKwkJCQltLT5tX3BrdGhkci5sZW4gPSAw Ow0KKwkJCQltLT5tX3BrdGhkci5yY3ZpZiA9IE5VTEw7IA0KKwkJCX0gZWxz ZSB7DQorCQkJCU1HRVQobSwgTV9UUllXQUlULCBNVF9EQVRBKTsNCisJCQkJ aWYgKG0gPT0gTlVMTCkgew0KKwkJCQkJZXJyb3IgPSBFTk9CVUZTOw0KKwkJ CQkJZ290byBvdXQ7DQorCQkJCX0NCisJCQl9DQorCQkJaWYgKHNvX3plcm9f Y29weV9zZW5kICYmDQorCQkJICAgIHJlc2lkPj1QQUdFX1NJWkUgJiYNCisJ CQkgICAgKnNwYWNlPj1QQUdFX1NJWkUgJiYNCisJCQkgICAgdWlvLT51aW9f aW92LT5pb3ZfbGVuPj1QQUdFX1NJWkUpIHsNCisJCQkJc29femVyb2NwX3N0 YXRzLnNpemVfb2srKzsNCisJCQkJc29femVyb2NwX3N0YXRzLmFsaWduX29r Kys7DQorCQkJCWNvd19zZW5kID0gc29jb3dfc2V0dXAobSwgdWlvKTsNCisJ CQkJbGVuID0gY293X3NlbmQ7DQorCQkJfQ0KKwkJCWlmICghY293X3NlbmQp IHsNCisJCQkJTUNMR0VUKG0sIE1fVFJZV0FJVCk7DQorCQkJCWlmICgobS0+ bV9mbGFncyAmIE1fRVhUKSA9PSAwKSB7DQorCQkJCQltX2ZyZWUobSk7DQor CQkJCQltID0gTlVMTDsNCisJCQkJfSBlbHNlIHsNCisJCQkJCWxlbiA9IG1p bihtaW4oTUNMQllURVMsIHJlc2lkKSwNCisJCQkJCSAgICAqc3BhY2UpOw0K KwkJCQl9DQorCQkJfQ0KKyNlbHNlIC8qIFpFUk9fQ09QWV9TT0NLRVRTICov DQorCQkJaWYgKHRvcCA9PSBOVUxMKSB7DQorCQkJCW0gPSBtX2dldGNsKE1f VFJZV0FJVCwgTVRfREFUQSwgTV9QS1RIRFIpOw0KKwkJCQltLT5tX3BrdGhk ci5sZW4gPSAwOw0KKwkJCQltLT5tX3BrdGhkci5yY3ZpZiA9IE5VTEw7DQor CQkJfSBlbHNlDQorCQkJCW0gPSBtX2dldGNsKE1fVFJZV0FJVCwgTVRfREFU QSwgMCk7DQorCQkJbGVuID0gbWluKG1pbihNQ0xCWVRFUywgcmVzaWQpLCAq c3BhY2UpOw0KKyNlbmRpZiAvKiBaRVJPX0NPUFlfU09DS0VUUyAqLw0KKwkJ fSBlbHNlIHsNCisJCQlpZiAodG9wID09IE5VTEwpIHsNCisJCQkJbSA9IG1f Z2V0aGRyKE1fVFJZV0FJVCwgTVRfREFUQSk7DQorCQkJCW0tPm1fcGt0aGRy LmxlbiA9IDA7DQorCQkJCW0tPm1fcGt0aGRyLnJjdmlmID0gTlVMTDsNCisN CisJCQkJbGVuID0gbWluKG1pbihNSExFTiwgcmVzaWQpLCAqc3BhY2UpOw0K KwkJCQkvKg0KKwkJCQkgKiBGb3IgZGF0YWdyYW0gcHJvdG9jb2xzLCBsZWF2 ZSByb29tDQorCQkJCSAqIGZvciBwcm90b2NvbCBoZWFkZXJzIGluIGZpcnN0 IG1idWYuDQorCQkJCSAqLw0KKwkJCQlpZiAoYXRvbWljICYmIG0gJiYgbGVu IDwgTUhMRU4pDQorCQkJCQlNSF9BTElHTihtLCBsZW4pOw0KKwkJCX0gZWxz ZSB7DQorCQkJCW0gPSBtX2dldChNX1RSWVdBSVQsIE1UX0RBVEEpOw0KKwkJ CQlsZW4gPSBtaW4obWluKE1MRU4sIHJlc2lkKSwgKnNwYWNlKTsNCisJCQl9 DQorCQl9DQorCQlpZiAobSA9PSBOVUxMKSB7DQorCQkJZXJyb3IgPSBFTk9C VUZTOw0KKwkJCWdvdG8gb3V0Ow0KKwkJfQ0KKw0KKwkJKnNwYWNlIC09IGxl bjsNCisjaWZkZWYgWkVST19DT1BZX1NPQ0tFVFMNCisJCWlmIChjb3dfc2Vu ZCkNCisJCQllcnJvciA9IDA7DQorCQllbHNlDQorI2VuZGlmIC8qIFpFUk9f Q09QWV9TT0NLRVRTICovDQorCQllcnJvciA9IHVpb21vdmUobXRvZChtLCB2 b2lkICopLCAoaW50KWxlbiwgdWlvKTsNCisJCXJlc2lkID0gdWlvLT51aW9f cmVzaWQ7DQorCQltLT5tX2xlbiA9IGxlbjsNCisJCSptcCA9IG07DQorCQl0 b3AtPm1fcGt0aGRyLmxlbiArPSBsZW47DQorCQlpZiAoZXJyb3IpDQorCQkJ Z290byBvdXQ7DQorCQltcCA9ICZtLT5tX25leHQ7DQorCQlpZiAocmVzaWQg PD0gMCkgew0KKwkJCWlmIChmbGFncyAmIE1TR19FT1IpDQorCQkJCXRvcC0+ bV9mbGFncyB8PSBNX0VPUjsNCisJCQlicmVhazsNCisJCX0NCisJfSB3aGls ZSAoKnNwYWNlID4gMCAmJiBhdG9taWMpOw0KK291dDoNCisJKnJldG1wID0g dG9wOw0KKwlyZXR1cm4gKGVycm9yKTsNCit9DQorDQogI2RlZmluZQlTQkxP Q0tXQUlUKGYpCSgoKGYpICYgTVNHX0RPTlRXQUlUKSA/IE1fTk9XQUlUIDog TV9XQUlUT0spDQorDQoraW50DQorc29zZW5kX2RncmFtKHNvLCBhZGRyLCB1 aW8sIHRvcCwgY29udHJvbCwgZmxhZ3MsIHRkKQ0KKwlzdHJ1Y3Qgc29ja2V0 ICpzbzsNCisJc3RydWN0IHNvY2thZGRyICphZGRyOw0KKwlzdHJ1Y3QgdWlv ICp1aW87DQorCXN0cnVjdCBtYnVmICp0b3A7DQorCXN0cnVjdCBtYnVmICpj b250cm9sOw0KKwlpbnQgZmxhZ3M7DQorCXN0cnVjdCB0aHJlYWQgKnRkOw0K K3sNCisJbG9uZyBzcGFjZSwgcmVzaWQ7DQorCWludCBjbGVuID0gMCwgZXJy b3IsIGRvbnRyb3V0ZTsNCisJaW50IGF0b21pYyA9IHNvc2VuZGFsbGF0b25j ZShzbykgfHwgdG9wOw0KKw0KKwlLQVNTRVJUKHNvLT5zb190eXBlID09IFNP Q0tfREdSQU0sICgic29kZ3JhbV9zZW5kOiAhU09DS19ER1JBTSIpKTsNCisJ S0FTU0VSVChzby0+c29fcHJvdG8tPnByX2ZsYWdzICYgUFJfQVRPTUlDLA0K KwkgICAgKCJzb2RncmFtX3NlbmQ6ICFQUl9BVE9NSUMiKSk7DQorDQorCWlm ICh1aW8gIT0gTlVMTCkNCisJCXJlc2lkID0gdWlvLT51aW9fcmVzaWQ7DQor CWVsc2UNCisJCXJlc2lkID0gdG9wLT5tX3BrdGhkci5sZW47DQorCS8qDQor CSAqIEluIHRoZW9yeSByZXNpZCBzaG91bGQgYmUgdW5zaWduZWQuDQorCSAq IEhvd2V2ZXIsIHNwYWNlIG11c3QgYmUgc2lnbmVkLCBhcyBpdCBtaWdodCBi ZSBsZXNzIHRoYW4gMA0KKwkgKiBpZiB3ZSBvdmVyLWNvbW1pdHRlZCwgYW5k IHdlIG11c3QgdXNlIGEgc2lnbmVkIGNvbXBhcmlzb24NCisJICogb2Ygc3Bh Y2UgYW5kIHJlc2lkLiAgT24gdGhlIG90aGVyIGhhbmQsIGEgbmVnYXRpdmUg cmVzaWQNCisJICogY2F1c2VzIHVzIHRvIGxvb3Agc2VuZGluZyAwLWxlbmd0 aCBzZWdtZW50cyB0byB0aGUgcHJvdG9jb2wuDQorCSAqDQorCSAqIEFsc28g Y2hlY2sgdG8gbWFrZSBzdXJlIHRoYXQgTVNHX0VPUiBpc24ndCB1c2VkIG9u IFNPQ0tfU1RSRUFNDQorCSAqIHR5cGUgc29ja2V0cyBzaW5jZSB0aGF0J3Mg YW4gZXJyb3IuDQorCSAqLw0KKwlpZiAocmVzaWQgPCAwKSB7DQorCQllcnJv ciA9IEVJTlZBTDsNCisJCWdvdG8gb3V0Ow0KKwl9DQorDQorCWRvbnRyb3V0 ZSA9DQorCSAgICAoZmxhZ3MgJiBNU0dfRE9OVFJPVVRFKSAmJiAoc28tPnNv X29wdGlvbnMgJiBTT19ET05UUk9VVEUpID09IDA7DQorCWlmICh0ZCAhPSBO VUxMKQ0KKwkJdGQtPnRkX3Byb2MtPnBfc3RhdHMtPnBfcnUucnVfbXNnc25k Kys7DQorCWlmIChjb250cm9sICE9IE5VTEwpDQorCQljbGVuID0gY29udHJv bC0+bV9sZW47DQorDQorCVNPQ0tCVUZfTE9DSygmc28tPnNvX3NuZCk7DQor CWlmIChzby0+c29fc25kLnNiX3N0YXRlICYgU0JTX0NBTlRTRU5ETU9SRSkg ew0KKwkJU09DS0JVRl9VTkxPQ0soJnNvLT5zb19zbmQpOw0KKwkJZXJyb3Ig PSBFUElQRTsNCisJCWdvdG8gb3V0Ow0KKwl9DQorCWlmIChzby0+c29fZXJy b3IpIHsNCisJCWVycm9yID0gc28tPnNvX2Vycm9yOw0KKwkJc28tPnNvX2Vy cm9yID0gMDsNCisJCVNPQ0tCVUZfVU5MT0NLKCZzby0+c29fc25kKTsNCisJ CWdvdG8gb3V0Ow0KKwl9DQorCWlmICgoc28tPnNvX3N0YXRlICYgU1NfSVND T05ORUNURUQpID09IDApIHsNCisJCS8qDQorCQkgKiBgc2VuZHRvJyBhbmQg YHNlbmRtc2cnIGlzIGFsbG93ZWQgb24gYSBjb25uZWN0aW9uLQ0KKwkJICog YmFzZWQgc29ja2V0IGlmIGl0IHN1cHBvcnRzIGltcGxpZWQgY29ubmVjdC4N CisJCSAqIFJldHVybiBFTk9UQ09OTiBpZiBub3QgY29ubmVjdGVkIGFuZCBu byBhZGRyZXNzIGlzDQorCQkgKiBzdXBwbGllZC4NCisJCSAqLw0KKwkJaWYg KChzby0+c29fcHJvdG8tPnByX2ZsYWdzICYgUFJfQ09OTlJFUVVJUkVEKSAm Jg0KKwkJICAgIChzby0+c29fcHJvdG8tPnByX2ZsYWdzICYgUFJfSU1QTE9Q Q0wpID09IDApIHsNCisJCQlpZiAoKHNvLT5zb19zdGF0ZSAmIFNTX0lTQ09O RklSTUlORykgPT0gMCAmJg0KKwkJCSAgICAhKHJlc2lkID09IDAgJiYgY2xl biAhPSAwKSkgew0KKwkJCQlTT0NLQlVGX1VOTE9DSygmc28tPnNvX3NuZCk7 DQorCQkJCWVycm9yID0gRU5PVENPTk47DQorCQkJCWdvdG8gb3V0Ow0KKwkJ CX0NCisJCX0gZWxzZSBpZiAoYWRkciA9PSBOVUxMKSB7DQorCQkJaWYgKHNv LT5zb19wcm90by0+cHJfZmxhZ3MgJiBQUl9DT05OUkVRVUlSRUQpDQorCQkJ CWVycm9yID0gRU5PVENPTk47DQorCQkJZWxzZQ0KKwkJCQllcnJvciA9IEVE RVNUQUREUlJFUTsNCisJCQlTT0NLQlVGX1VOTE9DSygmc28tPnNvX3NuZCk7 DQorCQkJZ290byBvdXQ7DQorCQl9DQorCX0NCisNCisJLyoNCisJICogRG8g d2UgbmVlZCBNU0dfT09CIHN1cHBvcnQgaW4gU09DS19ER1JBTT8gIFNpZ25z IGhlcmUgbWF5IGJlIGENCisJICogcHJvYmxlbSBhbmQgbmVlZCBmaXhpbmcu DQorCSAqLw0KKwlzcGFjZSA9IHNic3BhY2UoJnNvLT5zb19zbmQpOw0KKwlp ZiAoZmxhZ3MgJiBNU0dfT09CKQ0KKwkJc3BhY2UgKz0gMTAyNDsNCisJc3Bh Y2UgLT0gY2xlbjsNCisJaWYgKHJlc2lkID4gc3BhY2UpIHsNCisJCWVycm9y ID0gRU1TR1NJWkU7DQorCQlnb3RvIG91dDsNCisJfQ0KKwlTT0NLQlVGX1VO TE9DSygmc28tPnNvX3NuZCk7DQorCWlmICh1aW8gPT0gTlVMTCkgew0KKwkJ cmVzaWQgPSAwOw0KKwkJaWYgKGZsYWdzICYgTVNHX0VPUikNCisJCQl0b3At Pm1fZmxhZ3MgfD0gTV9FT1I7DQorCX0gZWxzZSB7DQorCQllcnJvciA9IHNv c2VuZF9jb3B5aW4odWlvLCAmdG9wLCBhdG9taWMsICZzcGFjZSwgZmxhZ3Mp Ow0KKwkJaWYgKGVycm9yKQ0KKwkJCWdvdG8gb3V0Ow0KKwkJcmVzaWQgPSB1 aW8tPnVpb19yZXNpZDsNCisJfQ0KKwlLQVNTRVJUKHJlc2lkID09IDAsICgi c29zZW5kX2RncmFtOiByZXNpZCAhPSAwIikpOw0KKwkvKg0KKwkgKiBYWFhS VzogRnJvYmJpbmcgU09fRE9OVFJPVVRFIGhlcmUgaXMgZXZlbiB3b3JzZSB3 aXRob3V0IHNibG9jaw0KKwkgKiB0aGFuIHdpdGguDQorCSAqLw0KKwlpZiAo ZG9udHJvdXRlKSB7DQorCQlTT0NLX0xPQ0soc28pOw0KKwkJc28tPnNvX29w dGlvbnMgfD0gU09fRE9OVFJPVVRFOw0KKwkJU09DS19VTkxPQ0soc28pOw0K Kwl9DQorCS8qDQorCSAqIFhYWCBhbGwgdGhlIFNCU19DQU5UU0VORE1PUkUg Y2hlY2tzIHByZXZpb3VzbHkNCisJICogZG9uZSBjb3VsZCBiZSBvdXQgb2Yg ZGF0ZS4gIFdlIGNvdWxkIGhhdmUgcmVjaWV2ZWQNCisJICogYSByZXNldCBw YWNrZXQgaW4gYW4gaW50ZXJydXB0IG9yIG1heWJlIHdlIHNsZXB0DQorCSAq IHdoaWxlIGRvaW5nIHBhZ2UgZmF1bHRzIGluIHVpb21vdmUoKSBldGMuIFdl IGNvdWxkDQorCSAqIHByb2JhYmx5IHJlY2hlY2sgYWdhaW4gaW5zaWRlIHRo ZSBsb2NraW5nIHByb3RlY3Rpb24NCisJICogaGVyZSwgYnV0IHRoZXJlIGFy ZSBwcm9iYWJseSBvdGhlciBwbGFjZXMgdGhhdCB0aGlzDQorCSAqIGFsc28g aGFwcGVucy4gIFdlIG11c3QgcmV0aGluayB0aGlzLg0KKwkgKi8NCisJZXJy b3IgPSAoKnNvLT5zb19wcm90by0+cHJfdXNycmVxcy0+cHJ1X3NlbmQpKHNv LA0KKwkgICAgKGZsYWdzICYgTVNHX09PQikgPyBQUlVTX09PQiA6DQorCS8q DQorCSAqIElmIHRoZSB1c2VyIHNldCBNU0dfRU9GLCB0aGUgcHJvdG9jb2wN CisJICogdW5kZXJzdGFuZHMgdGhpcyBmbGFnIGFuZCBub3RoaW5nIGxlZnQg dG8NCisJICogc2VuZCB0aGVuIHVzZSBQUlVfU0VORF9FT0YgaW5zdGVhZCBv ZiBQUlVfU0VORC4NCisJICovDQorCSAgICAoKGZsYWdzICYgTVNHX0VPRikg JiYNCisJICAgICAoc28tPnNvX3Byb3RvLT5wcl9mbGFncyAmIFBSX0lNUExP UENMKSAmJg0KKwkgICAgIChyZXNpZCA8PSAwKSkgPw0KKwkJUFJVU19FT0Yg Og0KKwkJLyogSWYgdGhlcmUgaXMgbW9yZSB0byBzZW5kIHNldCBQUlVTX01P UkVUT0NPTUUgKi8NCisJCShyZXNpZCA+IDAgJiYgc3BhY2UgPiAwKSA/IFBS VVNfTU9SRVRPQ09NRSA6IDAsDQorCQl0b3AsIGFkZHIsIGNvbnRyb2wsIHRk KTsNCisJaWYgKGRvbnRyb3V0ZSkgew0KKwkJU09DS19MT0NLKHNvKTsNCisJ CXNvLT5zb19vcHRpb25zICY9IH5TT19ET05UUk9VVEU7DQorCQlTT0NLX1VO TE9DSyhzbyk7DQorCX0NCisJY2xlbiA9IDA7DQorCWNvbnRyb2wgPSBOVUxM Ow0KKwl0b3AgPSBOVUxMOw0KK291dDoNCisJaWYgKHRvcCAhPSBOVUxMKQ0K KwkJbV9mcmVlbSh0b3ApOw0KKwlpZiAoY29udHJvbCAhPSBOVUxMKQ0KKwkJ bV9mcmVlbShjb250cm9sKTsNCisJcmV0dXJuIChlcnJvcik7DQorfQ0KKw0K IC8qDQogICogU2VuZCBvbiBhIHNvY2tldC4NCiAgKiBJZiBzZW5kIG11c3Qg Z28gYWxsIGF0IG9uY2UgYW5kIG1lc3NhZ2UgaXMgbGFyZ2VyIHRoYW4NCkBA IC02MDIsMjIgKzg5Niw3IEBADQogICogbXVzdCBjaGVjayBmb3Igc2hvcnQg Y291bnRzIGlmIEVJTlRSL0VSRVNUQVJUIGFyZSByZXR1cm5lZC4NCiAgKiBE YXRhIGFuZCBjb250cm9sIGJ1ZmZlcnMgYXJlIGZyZWVkIG9uIHJldHVybi4N CiAgKi8NCi0NCi0jaWZkZWYgWkVST19DT1BZX1NPQ0tFVFMNCi1zdHJ1Y3Qg c29femVyb2NvcHlfc3RhdHN7DQotCWludCBzaXplX29rOw0KLQlpbnQgYWxp Z25fb2s7DQotCWludCBmb3VuZF9pZnA7DQotfTsNCi1zdHJ1Y3Qgc29femVy b2NvcHlfc3RhdHMgc29femVyb2NwX3N0YXRzID0gezAsMCwwfTsNCi0jaW5j bHVkZSA8bmV0aW5ldC9pbi5oPg0KLSNpbmNsdWRlIDxuZXQvcm91dGUuaD4N Ci0jaW5jbHVkZSA8bmV0aW5ldC9pbl9wY2IuaD4NCi0jaW5jbHVkZSA8dm0v dm0uaD4NCi0jaW5jbHVkZSA8dm0vdm1fcGFnZS5oPg0KLSNpbmNsdWRlIDx2 bS92bV9vYmplY3QuaD4NCi0jZW5kaWYgLypaRVJPX0NPUFlfU09DS0VUUyov DQotDQorI2RlZmluZQlzbmRlcnIoZXJybm8pCXsgZXJyb3IgPSAoZXJybm8p OyBnb3RvIHJlbGVhc2U7IH0NCiBpbnQNCiBzb3NlbmQoc28sIGFkZHIsIHVp bywgdG9wLCBjb250cm9sLCBmbGFncywgdGQpDQogCXN0cnVjdCBzb2NrZXQg KnNvOw0KQEAgLTYyOCwxNCArOTA3LDkgQEANCiAJaW50IGZsYWdzOw0KIAlz dHJ1Y3QgdGhyZWFkICp0ZDsNCiB7DQotCXN0cnVjdCBtYnVmICoqbXA7DQot CXN0cnVjdCBtYnVmICptOw0KLQlsb25nIHNwYWNlLCBsZW4gPSAwLCByZXNp ZDsNCisJbG9uZyBzcGFjZSwgcmVzaWQ7DQogCWludCBjbGVuID0gMCwgZXJy b3IsIGRvbnRyb3V0ZTsNCiAJaW50IGF0b21pYyA9IHNvc2VuZGFsbGF0b25j ZShzbykgfHwgdG9wOw0KLSNpZmRlZiBaRVJPX0NPUFlfU09DS0VUUw0KLQlp bnQgY293X3NlbmQ7DQotI2VuZGlmIC8qIFpFUk9fQ09QWV9TT0NLRVRTICov DQogDQogCWlmICh1aW8gIT0gTlVMTCkNCiAJCXJlc2lkID0gdWlvLT51aW9f cmVzaWQ7DQpAQCAtNjYzLDcgKzkzNyw2IEBADQogCQl0ZC0+dGRfcHJvYy0+ cF9zdGF0cy0+cF9ydS5ydV9tc2dzbmQrKzsNCiAJaWYgKGNvbnRyb2wgIT0g TlVMTCkNCiAJCWNsZW4gPSBjb250cm9sLT5tX2xlbjsNCi0jZGVmaW5lCXNu ZGVycihlcnJubykJeyBlcnJvciA9IChlcnJubyk7IGdvdG8gcmVsZWFzZTsg fQ0KIA0KIAlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0KIHJlc3RhcnQ6 DQpAQCAtNzEzLDE1MyArOTg2LDYxIEBADQogCQkJZ290byByZXN0YXJ0Ow0K IAkJfQ0KIAkJU09DS0JVRl9VTkxPQ0soJnNvLT5zb19zbmQpOw0KLQkJbXAg PSAmdG9wOw0KIAkJc3BhY2UgLT0gY2xlbjsNCiAJCWRvIHsNCi0JCSAgICBp ZiAodWlvID09IE5VTEwpIHsNCi0JCQkvKg0KLQkJCSAqIERhdGEgaXMgcHJl cGFja2FnZWQgaW4gInRvcCIuDQotCQkJICovDQotCQkJcmVzaWQgPSAwOw0K LQkJCWlmIChmbGFncyAmIE1TR19FT1IpDQotCQkJCXRvcC0+bV9mbGFncyB8 PSBNX0VPUjsNCi0JCSAgICB9IGVsc2UgZG8gew0KLSNpZmRlZiBaRVJPX0NP UFlfU09DS0VUUw0KLQkJCWNvd19zZW5kID0gMDsNCi0jZW5kaWYgLyogWkVS T19DT1BZX1NPQ0tFVFMgKi8NCi0JCQlpZiAocmVzaWQgPj0gTUlOQ0xTSVpF KSB7DQotI2lmZGVmIFpFUk9fQ09QWV9TT0NLRVRTDQotCQkJCWlmICh0b3Ag PT0gTlVMTCkgew0KLQkJCQkJTUdFVEhEUihtLCBNX1RSWVdBSVQsIE1UX0RB VEEpOw0KLQkJCQkJaWYgKG0gPT0gTlVMTCkgew0KLQkJCQkJCWVycm9yID0g RU5PQlVGUzsNCi0JCQkJCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0K LQkJCQkJCWdvdG8gcmVsZWFzZTsNCi0JCQkJCX0NCi0JCQkJCW0tPm1fcGt0 aGRyLmxlbiA9IDA7DQotCQkJCQltLT5tX3BrdGhkci5yY3ZpZiA9IE5VTEw7 IA0KLQkJCQl9IGVsc2Ugew0KLQkJCQkJTUdFVChtLCBNX1RSWVdBSVQsIE1U X0RBVEEpOw0KLQkJCQkJaWYgKG0gPT0gTlVMTCkgew0KLQkJCQkJCWVycm9y ID0gRU5PQlVGUzsNCi0JCQkJCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQp Ow0KLQkJCQkJCWdvdG8gcmVsZWFzZTsNCi0JCQkJCX0NCi0JCQkJfQ0KLQkJ CQlpZiAoc29femVyb19jb3B5X3NlbmQgJiYNCi0JCQkJICAgIHJlc2lkPj1Q QUdFX1NJWkUgJiYNCi0JCQkJICAgIHNwYWNlPj1QQUdFX1NJWkUgJiYNCi0J CQkJICAgIHVpby0+dWlvX2lvdi0+aW92X2xlbj49UEFHRV9TSVpFKSB7DQot CQkJCQlzb196ZXJvY3Bfc3RhdHMuc2l6ZV9vaysrOw0KLQkJCQkJc29femVy b2NwX3N0YXRzLmFsaWduX29rKys7DQotCQkJCQljb3dfc2VuZCA9IHNvY293 X3NldHVwKG0sIHVpbyk7DQotCQkJCQlsZW4gPSBjb3dfc2VuZDsNCi0JCQkJ fQ0KLQkJCQlpZiAoIWNvd19zZW5kKSB7DQotCQkJCQlNQ0xHRVQobSwgTV9U UllXQUlUKTsNCi0JCQkJCWlmICgobS0+bV9mbGFncyAmIE1fRVhUKSA9PSAw KSB7DQotCQkJCQkJbV9mcmVlKG0pOw0KLQkJCQkJCW0gPSBOVUxMOw0KLQkJ CQkJfSBlbHNlIHsNCi0JCQkJCQlsZW4gPSBtaW4obWluKE1DTEJZVEVTLCBy ZXNpZCksIHNwYWNlKTsNCi0JCQkJCX0NCi0JCQkJfQ0KLSNlbHNlIC8qIFpF Uk9fQ09QWV9TT0NLRVRTICovDQotCQkJCWlmICh0b3AgPT0gTlVMTCkgew0K LQkJCQkJbSA9IG1fZ2V0Y2woTV9UUllXQUlULCBNVF9EQVRBLCBNX1BLVEhE Uik7DQotCQkJCQltLT5tX3BrdGhkci5sZW4gPSAwOw0KLQkJCQkJbS0+bV9w a3RoZHIucmN2aWYgPSBOVUxMOw0KLQkJCQl9IGVsc2UNCi0JCQkJCW0gPSBt X2dldGNsKE1fVFJZV0FJVCwgTVRfREFUQSwgMCk7DQotCQkJCWxlbiA9IG1p bihtaW4oTUNMQllURVMsIHJlc2lkKSwgc3BhY2UpOw0KLSNlbmRpZiAvKiBa RVJPX0NPUFlfU09DS0VUUyAqLw0KKwkJCWlmICh1aW8gPT0gTlVMTCkgew0K KwkJCQlyZXNpZCA9IDA7DQorCQkJCWlmIChmbGFncyAmIE1TR19FT1IpDQor CQkJCQl0b3AtPm1fZmxhZ3MgfD0gTV9FT1I7DQogCQkJfSBlbHNlIHsNCi0J CQkJaWYgKHRvcCA9PSBOVUxMKSB7DQotCQkJCQltID0gbV9nZXRoZHIoTV9U UllXQUlULCBNVF9EQVRBKTsNCi0JCQkJCW0tPm1fcGt0aGRyLmxlbiA9IDA7 DQotCQkJCQltLT5tX3BrdGhkci5yY3ZpZiA9IE5VTEw7DQotDQotCQkJCQls ZW4gPSBtaW4obWluKE1ITEVOLCByZXNpZCksIHNwYWNlKTsNCi0JCQkJCS8q DQotCQkJCQkgKiBGb3IgZGF0YWdyYW0gcHJvdG9jb2xzLCBsZWF2ZSByb29t DQotCQkJCQkgKiBmb3IgcHJvdG9jb2wgaGVhZGVycyBpbiBmaXJzdCBtYnVm Lg0KLQkJCQkJICovDQotCQkJCQlpZiAoYXRvbWljICYmIG0gJiYgbGVuIDwg TUhMRU4pDQotCQkJCQkJTUhfQUxJR04obSwgbGVuKTsNCi0JCQkJfSBlbHNl IHsNCi0JCQkJCW0gPSBtX2dldChNX1RSWVdBSVQsIE1UX0RBVEEpOw0KLQkJ CQkJbGVuID0gbWluKG1pbihNTEVOLCByZXNpZCksIHNwYWNlKTsNCisJCQkJ ZXJyb3IgPSBzb3NlbmRfY29weWluKHVpbywgJnRvcCwgYXRvbWljLA0KKwkJ CQkgICAgJnNwYWNlLCBmbGFncyk7DQorCQkJCWlmIChlcnJvciAhPSAwKSB7 DQorCQkJCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0KKwkJCQkJZ290 byByZWxlYXNlOw0KIAkJCQl9DQorCQkJCXJlc2lkID0gdWlvLT51aW9fcmVz aWQ7DQogCQkJfQ0KLQkJCWlmIChtID09IE5VTEwpIHsNCi0JCQkJZXJyb3Ig PSBFTk9CVUZTOw0KLQkJCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0K LQkJCQlnb3RvIHJlbGVhc2U7DQotCQkJfQ0KLQ0KLQkJCXNwYWNlIC09IGxl bjsNCi0jaWZkZWYgWkVST19DT1BZX1NPQ0tFVFMNCi0JCQlpZiAoY293X3Nl bmQpDQotCQkJCWVycm9yID0gMDsNCi0JCQllbHNlDQotI2VuZGlmIC8qIFpF Uk9fQ09QWV9TT0NLRVRTICovDQotCQkJZXJyb3IgPSB1aW9tb3ZlKG10b2Qo bSwgdm9pZCAqKSwgKGludClsZW4sIHVpbyk7DQotCQkJcmVzaWQgPSB1aW8t PnVpb19yZXNpZDsNCi0JCQltLT5tX2xlbiA9IGxlbjsNCi0JCQkqbXAgPSBt Ow0KLQkJCXRvcC0+bV9wa3RoZHIubGVuICs9IGxlbjsNCi0JCQlpZiAoZXJy b3IpIHsNCi0JCQkJU09DS0JVRl9MT0NLKCZzby0+c29fc25kKTsNCi0JCQkJ Z290byByZWxlYXNlOw0KLQkJCX0NCi0JCQltcCA9ICZtLT5tX25leHQ7DQot CQkJaWYgKHJlc2lkIDw9IDApIHsNCi0JCQkJaWYgKGZsYWdzICYgTVNHX0VP UikNCi0JCQkJCXRvcC0+bV9mbGFncyB8PSBNX0VPUjsNCi0JCQkJYnJlYWs7 DQorCQkJaWYgKGRvbnRyb3V0ZSkgew0KKwkJCQlTT0NLX0xPQ0soc28pOw0K KwkJCQlzby0+c29fb3B0aW9ucyB8PSBTT19ET05UUk9VVEU7DQorCQkJCVNP Q0tfVU5MT0NLKHNvKTsNCiAJCQl9DQotCQkgICAgfSB3aGlsZSAoc3BhY2Ug PiAwICYmIGF0b21pYyk7DQotCQkgICAgaWYgKGRvbnRyb3V0ZSkgew0KLQkJ CSAgICBTT0NLX0xPQ0soc28pOw0KLQkJCSAgICBzby0+c29fb3B0aW9ucyB8 PSBTT19ET05UUk9VVEU7DQotCQkJICAgIFNPQ0tfVU5MT0NLKHNvKTsNCi0J CSAgICB9DQotCQkgICAgLyoNCi0JCSAgICAgKiBYWFggYWxsIHRoZSBTQlNf Q0FOVFNFTkRNT1JFIGNoZWNrcyBwcmV2aW91c2x5DQotCQkgICAgICogZG9u ZSBjb3VsZCBiZSBvdXQgb2YgZGF0ZS4gIFdlIGNvdWxkIGhhdmUgcmVjaWV2 ZWQNCi0JCSAgICAgKiBhIHJlc2V0IHBhY2tldCBpbiBhbiBpbnRlcnJ1cHQg b3IgbWF5YmUgd2Ugc2xlcHQNCi0JCSAgICAgKiB3aGlsZSBkb2luZyBwYWdl IGZhdWx0cyBpbiB1aW9tb3ZlKCkgZXRjLiBXZSBjb3VsZA0KLQkJICAgICAq IHByb2JhYmx5IHJlY2hlY2sgYWdhaW4gaW5zaWRlIHRoZSBsb2NraW5nIHBy b3RlY3Rpb24NCi0JCSAgICAgKiBoZXJlLCBidXQgdGhlcmUgYXJlIHByb2Jh Ymx5IG90aGVyIHBsYWNlcyB0aGF0IHRoaXMNCi0JCSAgICAgKiBhbHNvIGhh cHBlbnMuICBXZSBtdXN0IHJldGhpbmsgdGhpcy4NCi0JCSAgICAgKi8NCi0J CSAgICBlcnJvciA9ICgqc28tPnNvX3Byb3RvLT5wcl91c3JyZXFzLT5wcnVf c2VuZCkoc28sDQotCQkJKGZsYWdzICYgTVNHX09PQikgPyBQUlVTX09PQiA6 DQorCQkJLyoNCisJCQkgKiBYWFggYWxsIHRoZSBTQlNfQ0FOVFNFTkRNT1JF IGNoZWNrcyBwcmV2aW91c2x5DQorCQkJICogZG9uZSBjb3VsZCBiZSBvdXQg b2YgZGF0ZS4gIFdlIGNvdWxkIGhhdmUgcmVjaWV2ZWQNCisJCQkgKiBhIHJl c2V0IHBhY2tldCBpbiBhbiBpbnRlcnJ1cHQgb3IgbWF5YmUgd2Ugc2xlcHQN CisJCQkgKiB3aGlsZSBkb2luZyBwYWdlIGZhdWx0cyBpbiB1aW9tb3ZlKCkg ZXRjLiBXZSBjb3VsZA0KKwkJCSAqIHByb2JhYmx5IHJlY2hlY2sgYWdhaW4g aW5zaWRlIHRoZSBsb2NraW5nIHByb3RlY3Rpb24NCisJCQkgKiBoZXJlLCBi dXQgdGhlcmUgYXJlIHByb2JhYmx5IG90aGVyIHBsYWNlcyB0aGF0IHRoaXMN CisJCQkgKiBhbHNvIGhhcHBlbnMuICBXZSBtdXN0IHJldGhpbmsgdGhpcy4N CisJCQkgKi8NCisJCQllcnJvciA9ICgqc28tPnNvX3Byb3RvLT5wcl91c3Jy ZXFzLT5wcnVfc2VuZCkoc28sDQorCQkJICAgIChmbGFncyAmIE1TR19PT0Ip ID8gUFJVU19PT0IgOg0KIAkJCS8qDQogCQkJICogSWYgdGhlIHVzZXIgc2V0 IE1TR19FT0YsIHRoZSBwcm90b2NvbA0KIAkJCSAqIHVuZGVyc3RhbmRzIHRo aXMgZmxhZyBhbmQgbm90aGluZyBsZWZ0IHRvDQogCQkJICogc2VuZCB0aGVu IHVzZSBQUlVfU0VORF9FT0YgaW5zdGVhZCBvZiBQUlVfU0VORC4NCiAJCQkg Ki8NCi0JCQkoKGZsYWdzICYgTVNHX0VPRikgJiYNCi0JCQkgKHNvLT5zb19w cm90by0+cHJfZmxhZ3MgJiBQUl9JTVBMT1BDTCkgJiYNCi0JCQkgKHJlc2lk IDw9IDApKSA/DQorCQkJICAgICgoZmxhZ3MgJiBNU0dfRU9GKSAmJg0KKwkJ CSAgICAgKHNvLT5zb19wcm90by0+cHJfZmxhZ3MgJiBQUl9JTVBMT1BDTCkg JiYNCisJCQkgICAgIChyZXNpZCA8PSAwKSkgPw0KIAkJCQlQUlVTX0VPRiA6 DQogCQkJLyogSWYgdGhlcmUgaXMgbW9yZSB0byBzZW5kIHNldCBQUlVTX01P UkVUT0NPTUUgKi8NCi0JCQkocmVzaWQgPiAwICYmIHNwYWNlID4gMCkgPyBQ UlVTX01PUkVUT0NPTUUgOiAwLA0KLQkJCXRvcCwgYWRkciwgY29udHJvbCwg dGQpOw0KLQkJICAgIGlmIChkb250cm91dGUpIHsNCi0JCQkgICAgU09DS19M T0NLKHNvKTsNCi0JCQkgICAgc28tPnNvX29wdGlvbnMgJj0gflNPX0RPTlRS T1VURTsNCi0JCQkgICAgU09DS19VTkxPQ0soc28pOw0KLQkJICAgIH0NCi0J CSAgICBjbGVuID0gMDsNCi0JCSAgICBjb250cm9sID0gTlVMTDsNCi0JCSAg ICB0b3AgPSBOVUxMOw0KLQkJICAgIG1wID0gJnRvcDsNCi0JCSAgICBpZiAo ZXJyb3IpIHsNCi0JCQlTT0NLQlVGX0xPQ0soJnNvLT5zb19zbmQpOw0KLQkJ CWdvdG8gcmVsZWFzZTsNCi0JCSAgICB9DQorCQkJICAgIChyZXNpZCA+IDAg JiYgc3BhY2UgPiAwKSA/IFBSVVNfTU9SRVRPQ09NRSA6IDAsDQorCQkJICAg IHRvcCwgYWRkciwgY29udHJvbCwgdGQpOw0KKwkJCWlmIChkb250cm91dGUp IHsNCisJCQkJU09DS19MT0NLKHNvKTsNCisJCQkJc28tPnNvX29wdGlvbnMg Jj0gflNPX0RPTlRST1VURTsNCisJCQkJU09DS19VTkxPQ0soc28pOw0KKwkJ CX0NCisJCQljbGVuID0gMDsNCisJCQljb250cm9sID0gTlVMTDsNCisJCQl0 b3AgPSBOVUxMOw0KKwkJCWlmIChlcnJvcikgew0KKwkJCQlTT0NLQlVGX0xP Q0soJnNvLT5zb19zbmQpOw0KKwkJCQlnb3RvIHJlbGVhc2U7DQorCQkJfQ0K IAkJfSB3aGlsZSAocmVzaWQgJiYgc3BhY2UgPiAwKTsNCiAJCVNPQ0tCVUZf TE9DSygmc28tPnNvX3NuZCk7DQogCX0gd2hpbGUgKHJlc2lkKTsNCkBAIC04 NzcsNiArMTA1OCw3IEBADQogCQltX2ZyZWVtKGNvbnRyb2wpOw0KIAlyZXR1 cm4gKGVycm9yKTsNCiB9DQorI3VuZGVmIHNuZGVycg0KIA0KIC8qDQogICog VGhlIHBhcnQgb2Ygc29yZWNlaXZlKCkgdGhhdCBpbXBsZW1lbnRzIHJlYWRp bmcgbm9uLWlubGluZSBvdXQtb2YtYmFuZA0KSW5kZXg6IG5ldGluZXQvdWRw X3VzcnJlcS5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTog L2hvbWUvbmN2cy9zcmMvc3lzL25ldGluZXQvdWRwX3VzcnJlcS5jLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS4xNzUuMi45DQpkaWZmIC11IC1yMS4xNzUu Mi45IHVkcF91c3JyZXEuYw0KLS0tIG5ldGluZXQvdWRwX3VzcnJlcS5jCTI5 IERlYyAyMDA2IDE5OjI1OjQ5IC0wMDAwCTEuMTc1LjIuOQ0KKysrIG5ldGlu ZXQvdWRwX3VzcnJlcS5jCTEgTWFyIDIwMDcgMTE6Mjc6MzQgLTAwMDANCkBA IC0xMTUwLDYgKzExNTAsNyBAQA0KIAkucHJ1X2Rpc2Nvbm5lY3QgPQl1ZHBf ZGlzY29ubmVjdCwNCiAJLnBydV9wZWVyYWRkciA9CQl1ZHBfcGVlcmFkZHIs DQogCS5wcnVfc2VuZCA9CQl1ZHBfc2VuZCwNCisJLnBydV9zb3NlbmQgPQkJ c29zZW5kX2RncmFtLA0KIAkucHJ1X3NodXRkb3duID0JCXVkcF9zaHV0ZG93 biwNCiAJLnBydV9zb2NrYWRkciA9CQl1ZHBfc29ja2FkZHIsDQogCS5wcnVf c29zZXRsYWJlbCA9CWluX3BjYnNvc2V0bGFiZWwNCg== --0-429716139-1172748644=:13593-- From owner-freebsd-performance@FreeBSD.ORG Thu Mar 1 11:49:40 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E331E16A401 for ; Thu, 1 Mar 2007 11:49:40 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0E513C441 for ; Thu, 1 Mar 2007 11:49:40 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so321793ugh for ; Thu, 01 Mar 2007 03:49:39 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ClrA4BqrisbBYz0UbqOMjkNgiaexkt7RYiuRJKn5+RFgWvgDz9SX1sy6aXp58n/MdBWxxoQOjoBoCfJqHU58RxZ10teCvQSowgJeJ8mLyDKV2lvzxDQYMHq4AQL0XzuXANLSYwNa38nyXIZhaF8OzDxucQvYxPcvtkCj8mKov8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oKV8Ipdd6KvSh3Qjhh7dAFoyeHQO1neuPGvWfffP54DZaj0CKeLUkfDAhTNdJAbBGO3ni30tj7Js/f4Aj/8TAbWs7dY68AolPWgGov0pXwXOu8EZfyED4hoHryABLEPGpFJBXNdHlNRMlGqXTjmXrQjervzj1h4LIyBkl4XQ/LI= Received: by 10.82.175.2 with SMTP id x2mr535018bue.1172748180870; Thu, 01 Mar 2007 03:23:00 -0800 (PST) Received: by 10.82.135.17 with HTTP; Thu, 1 Mar 2007 03:23:00 -0800 (PST) Message-ID: <3aaaa3a0703010323x107b0857k93069a719c216df6@mail.gmail.com> Date: Thu, 1 Mar 2007 11:23:00 +0000 From: Chris To: "Justin Robertson" In-Reply-To: <45D4E76F.7040807@sk1llz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070207120426.CDEFC16A407@hub.freebsd.org> <200702151211.45177.fcash@ocis.net> <45D4D0D1.5020902@sk1llz.net> <200702151357.22075.fcash@ocis.net> <45D4E76F.7040807@sk1llz.net> Cc: freebsd-performance@freebsd.org Subject: Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 11:49:41 -0000 On 15/02/07, Justin Robertson wrote: > > This is definitely worst-case, it's simulating a DDoS attack at the > network. What is really surprising is that just 1mbps of traffic is able > to kill a 6.x box doing routing. If it were, say, 600mbps that I'd > understand as you're pushing over a million PPS. But 1mbps? :-\ > > > Freddie Cash wrote: > > On Thursday 15 February 2007 01:29 pm, Justin Robertson wrote: > > > >> Send a flood of 60 byte syn packets with the tcp sack option thru > >> it and check out what happens. It's pretty weird and I can't explain > >> why. If you block the packets on the box via ipfw it's fine, the second > >> it has to make a routing decision everything goes out the window, it > >> seems. There's 100% packet loss on all protocols. I'm not using NAT, > >> there are real IPs in different C classes on the other side of the box. > >> > > > > Is that something that would occur normally? Or is this a > > worst-case/stress-test trying to break things? How are you generating > > the packets? > > > > I'm not a network guru, and haven't done much in the way of > > network-related stress-testing, but I'm always looking for ways to do so. > > > > > > > -- > Justin > > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > does disabling sacks harden agsint syn floods then? I agree 1mbps of syn is a weak flood. Chris From owner-freebsd-performance@FreeBSD.ORG Thu Mar 1 15:49:00 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1834616A406 for ; Thu, 1 Mar 2007 15:49:00 +0000 (UTC) (envelope-from blyon@util2.sjc1.bitgravity.com) Received: from util2.sjc1.bitgravity.com (util2.sjc1.bitgravity.com [208.67.233.36]) by mx1.freebsd.org (Postfix) with ESMTP id 05FCD13C471 for ; Thu, 1 Mar 2007 15:48:59 +0000 (UTC) (envelope-from blyon@util2.sjc1.bitgravity.com) Received: from c-69-181-166-240.hsd1.ca.comcast.net ([69.181.166.240] helo=[192.168.1.197]) by util2.sjc1.bitgravity.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HMn1h-0002Ej-Uk; Thu, 01 Mar 2007 07:17:01 -0800 In-Reply-To: References: <20070224215508.GA41968@xor.obsecurity.org> <45E13410.7020505@he.iki.fi> <20070225071946.GA48242@xor.obsecurity.org> <45E14BAD.80909@he.iki.fi> <20070225084737.GA49231@xor.obsecurity.org> <5a0a9d6f0702260936u3408f8d8rd4cde9234b2f7776@mail.gmail.com> <45E54619.7000503@isc.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Barrett Lyon Date: Thu, 1 Mar 2007 07:16:29 -0800 To: freebsd-performance@freebsd.org X-Mailer: Apple Mail (2.752.2) Sender: blyon@util2.sjc1.bitgravity.com Cc: Kip Macy , Peter Losher Subject: Re: UDP performance. X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 15:49:00 -0000 I also have a few 10GbE interfaces and Ixia chassis that I can run tests with if someone wants to send me a spec. -Barrett Barrett Lyon email/sip/iax: blyon@blyon.com cell: +1.916.387.8649 On Mar 1, 2007, at 1:28 AM, Kip Macy wrote: >> We recently put a stock Fedora Core 6 and a stock FreeBSD 6.2 on the >> same HW (HP ProLiant DL320 G5 Dual Core Xeons w/ 16GB RAM) and >> running >> BIND 9.4.0 and a well known ccTLD zone that we slammed a query stream >> to. On a single threaded BIND, there was a 20% advantage to >> Linux, on a >> multi threaded build, Linux trounced FreeBSD (39k to 89k queries/sec) >> >> There's also been other analysis done by Marcelo Amarai @ Registro.br >> that was posted to freebsd-net back last September. >> >> http://lists.freebsd.org/pipermail/freebsd-net/2006-September/ >> 011748.html> > > I have a couple of dual Woodcrests running back-to-back over multiple > 10GigE cards that I'd like to do performance testing with. Did you use > the same testing methodology as Marcelo? If not can you go into more > detail on your setup and how to reproduce? > > -Kip > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance- > unsubscribe@freebsd.org" From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 09:54:42 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A70216A400 for ; Fri, 2 Mar 2007 09:54:42 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE1213C49D for ; Fri, 2 Mar 2007 09:54:42 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.66) with esmtp (envelope-from ) id <1HN4Di-0005ZQ-LV>; Fri, 02 Mar 2007 10:38:34 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.66) with esmtpsa (envelope-from ) id <1HN4Di-0004Af-KQ>; Fri, 02 Mar 2007 10:38:34 +0100 Message-ID: <45E7F09B.7070005@zedat.fu-berlin.de> Date: Fri, 02 Mar 2007 10:38:35 +0100 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 09:54:42 -0000 The last days I tried to figure out why some of my lab's FreeBSD boxes and also mine at home seem to be outperformed by some Linux setups around here and I saw something interesting. On my lab's FreeBSD 6.2/i386 box (ASUS P4P800, ICH5 with two SATA 150 ports, two SATA 300 drives attached) I copied big files (~ 5GB) from one drive to another while the box didn't do anything else than copying. I watched the copy process via 'systat -vmstat 1' and realized, that the value of 'KB/t' never go byond 128 (128kb buffer limit?). But more frustrating, I never got beyond 33 MB/s transfer rate although bonni/bonni++ told me both drives are capable doing much more (~75 MB/s each). At home, I use a FreeBSD 7.0-CURRENT box on an ASUS A8N32-SLI/nForce4-SLI based box, amd64 (no 32Bit compatibility). Two Hitachi T7K250 250 GB/SATA II drives build up a RAID 0 (nVidia MediaShield), and additionally there is a SAMSUNG Spinpoitn SP2004C attached to the controller. bonni results in 55 MB/s for the SP2004C alone and gives ~ 65 - 70 MB/s for the Hitachis, each and roughly 115 MB/s for the RAID 0. But copying from the single drive to the RAID 0 or from the RAID 0 to the single drive also reaches this oscure 33 MB/s boundary! In the first place I thought the older i386 hardware has some hard-limits, but we have several boxes of the exact same hardware around here and a wide spread Linux and Windows utilization and on those boxes equipted with more than one harddrive (PATA or SATA) the effective transfer rate shown up is about 50 - 65 MB/s as expected with copying a big 5G file from one drive to another. The hardwrae limit is completely nonsense when it comes to the AMD64 box with newer hardware. Before digging into this problem deeper with benchmarks, could anyone explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33 defaults, but on both boxes nForce4 and ICH5 controller are recognized and show up with SATA300 or SATA150 capabilities, respective)? May I have some knobs I'm not aware of to tune disk performance? I would appreciate any coments on that and if someone has some good ideas how to benchmark those subjects, please let me know. Regards, Oliver -- From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 10:24:19 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E5B416A400 for ; Fri, 2 Mar 2007 10:24:19 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from mail.freebsd-corp-net-guide.com (mail.web-strider.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id C442A13C4A7 for ; Fri, 2 Mar 2007 10:24:18 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from coolf89ea26645 (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.13.8/8.13.8) with SMTP id l229kZt5071813; Fri, 2 Mar 2007 01:46:36 -0800 (PST) (envelope-from tedm@toybox.placo.com) Message-ID: <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> From: "Ted Mittelstaedt" To: "O. Hartmann" , , References: <45E7F09B.7070005@zedat.fu-berlin.de> Date: Fri, 2 Mar 2007 01:45:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.freebsd-corp-net-guide.com [65.75.192.90]); Fri, 02 Mar 2007 01:46:36 -0800 (PST) Cc: Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 10:24:19 -0000 ----- Original Message ----- From: "O. Hartmann" To: ; Sent: Friday, March 02, 2007 1:38 AM Subject: (S)ATA performance in FBSD 6.2/7.0 > The last days I tried to figure out why some of my lab's FreeBSD boxes > and also mine at home seem to be outperformed by some Linux setups > around here and I saw something interesting. > blah blah blah deleted > > Before digging into this problem deeper with benchmarks, could anyone > explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33 man mount read section on "async" linux by default mounts async freebsd by default mounts sync you can change FBSD to async then watch your fs scramble during a power failure no big deal, it's only your data. Ted From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 10:35:57 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5144016A406 for ; Fri, 2 Mar 2007 10:35:57 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30315.mail.mud.yahoo.com (web30315.mail.mud.yahoo.com [209.191.69.77]) by mx1.freebsd.org (Postfix) with SMTP id 00A0413C49D for ; Fri, 2 Mar 2007 10:35:56 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: (qmail 80688 invoked by uid 60001); 2 Mar 2007 10:35:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1IekMctHDEZWnuBPlzhebeUXhKRGZ4SaDqEbuwdu8aYndp2TARzkBWy+UcXE8qa4MYUJkXWQjt7jPT7Tel6Z8GQXIn2nM6ksVdxWiT4lBh4Cnlj3qUNiuxBTzE+/coVvT14YDzIA0t8EhlqVvEL8TslFanIQaFBdgIYtaVxvCSk=; X-YMail-OSG: cxwZgqAVM1mTUs23ECHL8WM9QuV8Y.4_mb6LhJz1.KUreygZWprx8_g2ZQZGcWdegfmZjMAYEvgaS7mQOVyQSSjKKfpCckuOGt2iR9acHQ7wCu8IQg5EJSRxneSUsx7EJNVKvOVziuP4cRo._01ejkBcTw-- Received: from [85.212.11.231] by web30315.mail.mud.yahoo.com via HTTP; Fri, 02 Mar 2007 02:35:56 PST Date: Fri, 2 Mar 2007 02:35:56 -0800 (PST) From: "R. B. Riddick" To: "O. Hartmann" , freebsd-performance@freebsd.org, freebsd-questions@freebsd.org In-Reply-To: <45E7F09B.7070005@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <455296.79993.qm@web30315.mail.mud.yahoo.com> Cc: Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 10:35:57 -0000 --- "O. Hartmann" wrote: > Before digging into this problem deeper with benchmarks, could anyone > explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33 > defaults, but on both boxes nForce4 and ICH5 controller are recognized > and show up with SATA300 or SATA150 capabilities, respective)? May I > have some knobs I'm not aware of to tune disk performance? > I think, this 33MB/sec limit comes like this: The regular copy process (I think u used "cp") reads with speed S from disk A and writes with speed S to disk B. But: While it reads, it doesnt write AND while it writes, it doesnt read. So you might want to try this: dd if=/diskA/fileA bs=128k | dd of=/diskB/fileB bs=128k You could also try just to read or to write. Or to read&write with _independent_ processes. -Arne ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 11:38:48 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CACAB16A401 for ; Fri, 2 Mar 2007 11:38:48 +0000 (UTC) (envelope-from cheffo@FreeBSD-BG.org) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 3765513C471 for ; Fri, 2 Mar 2007 11:38:48 +0000 (UTC) (envelope-from cheffo@FreeBSD-BG.org) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id CF9C41B10ED2; Fri, 2 Mar 2007 12:38:46 +0100 (CET) Received: from [192.168.3.125] (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 507001B10EA4; Fri, 2 Mar 2007 12:38:46 +0100 (CET) Message-ID: <45E80CC5.8080607@FreeBSD-BG.org> Date: Fri, 02 Mar 2007 13:38:45 +0200 From: Cheffo User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: Ted Mittelstaedt References: <45E7F09B.7070005@zedat.fu-berlin.de> <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> In-Reply-To: <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: freebsd-performance@freebsd.org, "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 11:38:48 -0000 Hi, Ted Mittelstaedt wrote: > ----- Original Message ----- > From: "O. Hartmann" > To: ; > Sent: Friday, March 02, 2007 1:38 AM > Subject: (S)ATA performance in FBSD 6.2/7.0 > > >> The last days I tried to figure out why some of my lab's FreeBSD boxes >> and also mine at home seem to be outperformed by some Linux setups >> around here and I saw something interesting. >> > > blah blah blah deleted > >> Before digging into this problem deeper with benchmarks, could anyone >> explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33 > > man mount > > read section on "async" > > linux by default mounts async > > freebsd by default mounts sync > > you can change FBSD to async > > then watch your fs scramble during a power failure > > no big deal, it's only your data. > > Ted If SYNC is default how can you explain this: [12:58]root@hater:~# mount /dev/ad4s3a on / (ufs, local, synchronous) devfs on /dev (devfs, local) /dev/ad4s3d on /tmp (ufs, local, soft-updates) /dev/ad4s3f on /usr (ufs, local, soft-updates) /dev/ad4s3e on /var (ufs, local, soft-updates) [13:00]root@hater:~# cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ad4s3b none swap sw 0 0 /dev/ad4s3a / ufs rw,sync 1 1 /dev/ad4s3d /tmp ufs rw 2 2 /dev/ad4s3f /usr ufs rw 2 2 /dev/ad4s3e /var ufs rw 2 2 And this is only because I manually add *sync* to my /etc/fstab. E.g if sync is default why mount do not report that my /dev/ad4s3f on /usr is mounted synchronous? From what I seed in rc.X scripts mount -a -t ${mount_excludes} is used to mount things form fstab at boot time (sync or async is not set anywhere so we use dafault options here) So I'm pretty sure that for type ufs async is default. Also I do not see why sync should report different speeds for copy and benchmark tools if they do the same thing? Just to be sure I added to my /tmp entry async in /etc/fstab: /dev/ad4s3d /tmp ufs rw,async 2 2 umounted and mounted again and still have: /dev/ad4s3d on /tmp (ufs, local, soft-updates) I think the problem is that the benchmark runs with small files and most files are in cache that's why it shows higher speeds - try to run bonnie++ with more and bigger files to be sure that the cache is not enough and to be able to see the real performance of your HDDs. PS: Here is what I got from RAID10 4x160GB SATA2 HDDs (areca RAID) BLAH - bonnie++ -d /var/tmp -u root -s 16g -n 256:65536:65536:16 Version 1.93c ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP blah.cmotd.com 16G 159 88 54264 24 24727 12 299 94 70744 19 223.5 12 Latency 63581us 803ms 1123ms 93936us 94991us 251ms Version 1.93c ------Sequential Create------ --------Random Create-------- blah.cmotd.com -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 256:65536:65536/16 715 24 826 25 17321 49 733 24 51 2 6039 70 Latency 1220ms 408ms 2805ms 1189ms 692ms 2735ms 50MB/s write & 70MB/s read from 4HDDs .. so I do not know how you expect 75MB/s with single HDD. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 12:03:55 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1814316A401; Fri, 2 Mar 2007 12:03:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 9819213C4AC; Fri, 2 Mar 2007 12:03:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5D618.dip.t-dialin.net [84.165.214.24]) by redbull.bpaserver.net (Postfix) with ESMTP id 24F8F2E168; Fri, 2 Mar 2007 13:03:50 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 62CCA5B4817; Fri, 2 Mar 2007 13:03:47 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l22C3kR9024262; Fri, 2 Mar 2007 13:03:46 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from proxy.Leidinger.net (proxy.Leidinger.net [192.168.1.103]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 02 Mar 2007 13:03:46 +0100 Message-ID: <20070302130346.1ipa5epugws4scgw@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 02 Mar 2007 13:03:46 +0100 From: Alexander Leidinger To: Cheffo References: <45E7F09B.7070005@zedat.fu-berlin.de> <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> <45E80CC5.8080607@FreeBSD-BG.org> In-Reply-To: <45E80CC5.8080607@FreeBSD-BG.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.187, required 8, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, J_CHICKENPOX_25 0.60, TW_EV 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-performance@freebsd.org, "O. Hartmann" , freebsd-questions@freebsd.org, Ted Mittelstaedt Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 12:03:55 -0000 Quoting Cheffo (from Fri, 02 Mar 2007 13:38:45 +0200= ): > Hi, > > > Ted Mittelstaedt wrote: >> ----- Original Message ----- From: "O. Hartmann" =20 >> >> To: ; >> Sent: Friday, March 02, 2007 1:38 AM >> Subject: (S)ATA performance in FBSD 6.2/7.0 >>> The last days I tried to figure out why some of my lab's FreeBSD =20 >>> boxes and also mine at home seem to be outperformed by some Linux =20 >>> setups around here and I saw something interesting. >>> >> >> blah blah blah deleted >> >>> Before digging into this problem deeper with benchmarks, could =20 >>> anyone explain why FreeBSD reaches this 33 MB/s limit (sounds like =20 >>> UDMA 33 >> >> man mount >> >> read section on "async" >> >> linux by default mounts async >> >> freebsd by default mounts sync >> >> you can change FBSD to async >> >> then watch your fs scramble during a power failure >> >> no big deal, it's only your data. >> >> Ted > > If SYNC is default how can you explain this: > > [12:58]root@hater:~# mount > /dev/ad4s3a on / (ufs, local, synchronous) > devfs on /dev (devfs, local) > /dev/ad4s3d on /tmp (ufs, local, soft-updates) > /dev/ad4s3f on /usr (ufs, local, soft-updates) > /dev/ad4s3e on /var (ufs, local, soft-updates) [...] > So I'm pretty sure that for type ufs async is default. Both of you are wrong. By default "noasync" is used. This is different =20 from sync and async. Feel free to look up the difference. > Also I do not see why sync should report different speeds for copy and > benchmark tools if they do the same thing? Because cp may behave differently than the tools used to benchmark. A =20 dd may be more portable in this case. > Just to be sure I added to my /tmp entry async in /etc/fstab: > /dev/ad4s3d /tmp ufs rw,async 2 2 > > umounted and mounted again and still have: > /dev/ad4s3d on /tmp (ufs, local, soft-updates) IIRC when SU is used, async is not used even if specified. But I' not =20 sure about this. Asides from the linux async-by-default there's maybe also the =20 write-cache-off penalty in FreeBSD. But I'm not sure it is off by =20 default. I disable the WC myself in loader.conf everywhere to be on =20 the safe side and I don't feel like experimenting ATM (I'm ill in bed). If the same conditions are tested in FreeBSD and linux (which is not =20 easy, as we don't share a common FS implementation, even when we =20 support the same FS type) and the sync/async and WC related stuff can =20 be ruled out, it may be a problem in the (S)ATA code and it would be =20 nice if we would know about this. So please dig deeper into this (it =20 can also be a problem with our cp or GEOM or whatever). Bye, Alexander. --=20 "I heard one time you single-handedly defeated a hoard of rampaging of somethings in the something something system." -Fry http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 10:13:03 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6744216A408; Fri, 2 Mar 2007 10:13:03 +0000 (UTC) (envelope-from wojtek@tensor.3miasto.net) Received: from chylonia.3miasto.net (chylonia.3miasto.net [83.12.228.78]) by mx1.freebsd.org (Postfix) with ESMTP id CF90413C481; Fri, 2 Mar 2007 10:13:02 +0000 (UTC) (envelope-from wojtek@tensor.3miasto.net) Received: from chylonia.3miasto.net (localhost [127.0.0.1]) by chylonia.3miasto.net (8.13.8/8.13.4) with ESMTP id l22AD191008492; Fri, 2 Mar 2007 11:13:01 +0100 (CET) (envelope-from wojtek@tensor.3miasto.net) Received: from localhost (wojtek@localhost) by chylonia.3miasto.net (8.13.8/8.13.4/Submit) with ESMTP id l22AD1cW008489; Fri, 2 Mar 2007 11:13:01 +0100 (CET) (envelope-from wojtek@tensor.3miasto.net) X-Authentication-Warning: chylonia.3miasto.net: wojtek owned process doing -bs Date: Fri, 2 Mar 2007 11:13:01 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@chylonia.3miasto.net To: Ted Mittelstaedt In-Reply-To: <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> Message-ID: <20070302111208.J8367@chylonia.3miasto.net> References: <45E7F09B.7070005@zedat.fu-berlin.de> <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 02 Mar 2007 12:37:49 +0000 Cc: freebsd-performance@freebsd.org, "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 10:13:03 -0000 > > you can change FBSD to async > > then watch your fs scramble during a power failure > > no big deal, it's only your data. > you are wrong, he talked about copying BIG files, and this shouldn't make a difference contrary to small files. there is something wrong there as i routinely get 70MB/s on my SATA server From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 10:23:10 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5D9A16A401 for ; Fri, 2 Mar 2007 10:23:10 +0000 (UTC) (envelope-from wojtek@tensor.3miasto.net) Received: from chylonia.3miasto.net (chylonia.3miasto.net [83.12.228.78]) by mx1.freebsd.org (Postfix) with ESMTP id 4107513C4B2 for ; Fri, 2 Mar 2007 10:23:09 +0000 (UTC) (envelope-from wojtek@tensor.3miasto.net) Received: from chylonia.3miasto.net (localhost [127.0.0.1]) by chylonia.3miasto.net (8.13.8/8.13.4) with ESMTP id l229hY1v005982; Fri, 2 Mar 2007 10:43:34 +0100 (CET) (envelope-from wojtek@tensor.3miasto.net) Received: from localhost (wojtek@localhost) by chylonia.3miasto.net (8.13.8/8.13.4/Submit) with ESMTP id l229hY7G005979; Fri, 2 Mar 2007 10:43:34 +0100 (CET) (envelope-from wojtek@tensor.3miasto.net) X-Authentication-Warning: chylonia.3miasto.net: wojtek owned process doing -bs Date: Fri, 2 Mar 2007 10:43:34 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@chylonia.3miasto.net To: "O. Hartmann" In-Reply-To: <45E7F09B.7070005@zedat.fu-berlin.de> Message-ID: <20070302104219.B5845@chylonia.3miasto.net> References: <45E7F09B.7070005@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 02 Mar 2007 12:37:59 +0000 Cc: freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 10:23:10 -0000 > another while the box didn't do anything else than copying. I watched the > copy process via 'systat -vmstat 1' and realized, that the value of 'KB/t' > never go byond 128 (128kb buffer limit?). But more frustrating, I never got what's wrong? FreeBSD uses 128k limit by default. edit /usr/src/sys/sys/param.h and change #define MAXPHYS (128 * 1024) /* max raw I/O transfer size */ to say #define MAXPHYS (1024 * 1024) /* max raw I/O transfer size */ From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 12:59:58 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 330BC16A5B4 for ; Fri, 2 Mar 2007 12:59:58 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id AAE8513C4A7 for ; Fri, 2 Mar 2007 12:59:57 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l22BgLeS074567 for ; Fri, 2 Mar 2007 08:42:21 -0300 (BRT) (envelope-from tec@mega.net.br) From: NOC Meganet Organization: Prowip Telecom Ltda To: freebsd-performance@freebsd.org Date: Fri, 2 Mar 2007 08:42:22 -0300 User-Agent: KMail/1.9.5 References: <45E7F09B.7070005@zedat.fu-berlin.de> <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> In-Reply-To: <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703020842.23082.tec@mega.net.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 12:59:58 -0000 On Friday 02 March 2007 06:45, Ted Mittelstaedt wrote: > blah blah blah deleted > idem ;) > > Before digging into this problem deeper with benchmarks, could anyone > > explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33 > > man mount > > read section on "async" > > linux by default mounts async > > freebsd by default mounts sync > > you can change FBSD to async > > then watch your fs scramble during a power failure > > no big deal, it's only your data. > big deal however is if it is a FBSD flaw or not since you do already compare I like to add that this scramble thing does not happen on Linux as far as I remember but I must admit I never tested it, I only observed it after powerfailure on some redhat WSs I have but anyway cp or dd probably is not a performance measurement tool at all and a software should take proper care of disk i/o whatever fs it is installed on I do not know if it makes any sense discussing cp or dd performance HM A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 13:35:16 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD4D416A408; Fri, 2 Mar 2007 13:35:16 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8670113C4B2; Fri, 2 Mar 2007 13:35:16 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l22DZ95Z005732; Fri, 2 Mar 2007 07:35:10 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45E8280D.9020508@freebsd.org> Date: Fri, 02 Mar 2007 07:35:09 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: Alexander Leidinger References: <45E7F09B.7070005@zedat.fu-berlin.de> <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> <45E80CC5.8080607@FreeBSD-BG.org> <20070302130346.1ipa5epugws4scgw@webmail.leidinger.net> In-Reply-To: <20070302130346.1ipa5epugws4scgw@webmail.leidinger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2697/Fri Mar 2 06:02:13 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-performance@freebsd.org, "O. Hartmann" , Cheffo , Ted Mittelstaedt , freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 13:35:16 -0000 On 03/02/07 06:03, Alexander Leidinger wrote: > Quoting Cheffo (from Fri, 02 Mar 2007 13:38:45 +0200): > >> Hi, >> >> >> Ted Mittelstaedt wrote: >>> ----- Original Message ----- From: "O. Hartmann" >>> >>> To: ; >>> Sent: Friday, March 02, 2007 1:38 AM >>> Subject: (S)ATA performance in FBSD 6.2/7.0 >>>> The last days I tried to figure out why some of my lab's FreeBSD >>>> boxes and also mine at home seem to be outperformed by some Linux >>>> setups around here and I saw something interesting. >>>> >>> blah blah blah deleted >>> >>>> Before digging into this problem deeper with benchmarks, could >>>> anyone explain why FreeBSD reaches this 33 MB/s limit (sounds like >>>> UDMA 33 >>> man mount >>> >>> read section on "async" >>> >>> linux by default mounts async >>> >>> freebsd by default mounts sync >>> >>> you can change FBSD to async >>> >>> then watch your fs scramble during a power failure >>> >>> no big deal, it's only your data. >>> >>> Ted >> If SYNC is default how can you explain this: >> >> [12:58]root@hater:~# mount >> /dev/ad4s3a on / (ufs, local, synchronous) >> devfs on /dev (devfs, local) >> /dev/ad4s3d on /tmp (ufs, local, soft-updates) >> /dev/ad4s3f on /usr (ufs, local, soft-updates) >> /dev/ad4s3e on /var (ufs, local, soft-updates) > [...] >> So I'm pretty sure that for type ufs async is default. > > Both of you are wrong. By default "noasync" is used. This is different > from sync and async. Feel free to look up the difference. > >> Also I do not see why sync should report different speeds for copy and >> benchmark tools if they do the same thing? > > Because cp may behave differently than the tools used to benchmark. A > dd may be more portable in this case. > >> Just to be sure I added to my /tmp entry async in /etc/fstab: >> /dev/ad4s3d /tmp ufs rw,async 2 2 >> >> umounted and mounted again and still have: >> /dev/ad4s3d on /tmp (ufs, local, soft-updates) > > IIRC when SU is used, async is not used even if specified. But I' not > sure about this. > > > Asides from the linux async-by-default there's maybe also the > write-cache-off penalty in FreeBSD. But I'm not sure it is off by > default. I disable the WC myself in loader.conf everywhere to be on > the safe side and I don't feel like experimenting ATM (I'm ill in bed). > > If the same conditions are tested in FreeBSD and linux (which is not > easy, as we don't share a common FS implementation, even when we > support the same FS type) and the sync/async and WC related stuff can > be ruled out, it may be a problem in the (S)ATA code and it would be > nice if we would know about this. So please dig deeper into this (it > can also be a problem with our cp or GEOM or whatever). People should not be using file system tools to measure hardware speeds like SATA or disks. That doesn't make sense, since a portion of that benchmark would then include the file system, which as you mention is very very different between OS'es. cp shouldn't be used. dd is ok for bare minimum testing I suppose. On one of my SATA memory disks, I can get 125MB/s through it, with no extra magic. Eric From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 15:01:20 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C12216A400 for ; Fri, 2 Mar 2007 15:01:20 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id D6ABB13C48D for ; Fri, 2 Mar 2007 15:01:19 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l22EmY5t087454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2007 15:48:34 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l22EmYww087451; Fri, 2 Mar 2007 15:48:34 +0100 (CET) Date: Fri, 2 Mar 2007 15:48:34 +0100 From: Divacky Roman To: Wojciech Puchar Message-ID: <20070302144833.GA87211@stud.fit.vutbr.cz> References: <45E7F09B.7070005@zedat.fu-berlin.de> <20070302104219.B5845@chylonia.3miasto.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070302104219.B5845@chylonia.3miasto.net> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: freebsd-performance@freebsd.org, "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 15:01:20 -0000 On Fri, Mar 02, 2007 at 10:43:34AM +0100, Wojciech Puchar wrote: > >another while the box didn't do anything else than copying. I watched the > >copy process via 'systat -vmstat 1' and realized, that the value of 'KB/t' > >never go byond 128 (128kb buffer limit?). But more frustrating, I never got > > what's wrong? FreeBSD uses 128k limit by default. > > edit /usr/src/sys/sys/param.h > > and change > > #define MAXPHYS (128 * 1024) /* max raw I/O transfer size */ > > > to say > > #define MAXPHYS (1024 * 1024) /* max raw I/O transfer size */ did anyone measure impact on various benchmark of this change? is 128k the optimal size for "nowadays computers" ? if we can squeeze more performance out of a typical box by just raising one define it would be great... roman From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 15:57:48 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9A3016A407 for ; Fri, 2 Mar 2007 15:57:48 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id 0BCB413C4A3 for ; Fri, 2 Mar 2007 15:57:47 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l22FSX3b079624; Fri, 2 Mar 2007 09:28:33 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l22FSX0d079623; Fri, 2 Mar 2007 09:28:33 -0600 (CST) (envelope-from brooks) Date: Fri, 2 Mar 2007 09:28:33 -0600 From: Brooks Davis To: "O. Hartmann" Message-ID: <20070302152832.GA79187@lor.one-eyed-alien.net> References: <45E7F09B.7070005@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <45E7F09B.7070005@zedat.fu-berlin.de> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 02 Mar 2007 09:28:33 -0600 (CST) X-Mailman-Approved-At: Fri, 02 Mar 2007 17:02:27 +0000 Cc: freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 15:57:48 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 02, 2007 at 10:38:35AM +0100, O. Hartmann wrote: > The last days I tried to figure out why some of my lab's FreeBSD boxes=20 > and also mine at home seem to be outperformed by some Linux setups=20 > around here and I saw something interesting. >=20 > On my lab's FreeBSD 6.2/i386 box (ASUS P4P800, ICH5 with two SATA 150=20 > ports, two SATA 300 drives attached) I copied big files (~ 5GB) from one= =20 > drive to another while the box didn't do anything else than copying. I=20 > watched the copy process via 'systat -vmstat 1' and realized, that the=20 > value of 'KB/t' never go byond 128 (128kb buffer limit?). But more=20 > frustrating, I never got beyond 33 MB/s transfer rate although=20 > bonni/bonni++ told me both drives are capable doing much more (~75 MB/s= =20 > each). > At home, I use a FreeBSD 7.0-CURRENT box on an ASUS=20 > A8N32-SLI/nForce4-SLI based box, amd64 (no 32Bit compatibility). Two=20 > Hitachi T7K250 250 GB/SATA II drives build up a RAID 0 (nVidia=20 > MediaShield), and additionally there is a SAMSUNG Spinpoitn SP2004C=20 > attached to the controller. bonni results in 55 MB/s for the SP2004C=20 > alone and gives ~ 65 - 70 MB/s for the Hitachis, each and roughly 115=20 > MB/s for the RAID 0. But copying from the single drive to the RAID 0 or= =20 > from the RAID 0 to the single drive also reaches this oscure 33 MB/s=20 > boundary! >=20 > In the first place I thought the older i386 hardware has some=20 > hard-limits, but we have several boxes of the exact same hardware around= =20 > here and a wide spread Linux and Windows utilization and on those boxes= =20 > equipted with more than one harddrive (PATA or SATA) the effective=20 > transfer rate shown up is about 50 - 65 MB/s as expected with copying a= =20 > big 5G file from one drive to another. >=20 > The hardwrae limit is completely nonsense when it comes to the AMD64 box= =20 > with newer hardware. >=20 > Before digging into this problem deeper with benchmarks, could anyone=20 > explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33=20 > defaults, but on both boxes nForce4 and ICH5 controller are recognized=20 > and show up with SATA300 or SATA150 capabilities, respective)? May I=20 > have some knobs I'm not aware of to tune disk performance? >=20 > I would appreciate any coments on that and if someone has some good=20 > ideas how to benchmark those subjects, please let me know. One thing to keep in mind is that it matters a lot were on the disk you place the data due to the higher angular density of data at the outside of the disk. The results you are seeing are close to consistant with the kind of results I'd expect to see from writing at opposiste edges of the disk. The 33MB/s is suspious ane may diserve investigation, but make sure you are writing to the same part of the disk if you want to compare disk IO rates. There's an example of IO rates on recent large SATA disks: http://storagereview.com/articles/200607/500_2.html Also, you should time the actual copy and do the math to verify that vmstat is actually producing valid results. It's possible there's a bug in vmstat or the underlying statistics it uses. -- Brooks --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF6EKgXY6L6fI4GtQRArzYAJ4yi9tMIlmHB54psVhyicUGojfGJwCZARVf riI6eItmgtXAXpgi611e1vM= =iKHp -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 18:51:01 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F46416A405; Fri, 2 Mar 2007 18:51:01 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6BA4913C49D; Fri, 2 Mar 2007 18:51:01 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l22IowaM063935; Fri, 2 Mar 2007 12:50:58 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45E87212.1010208@freebsd.org> Date: Fri, 02 Mar 2007 12:50:58 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: Brooks Davis References: <45E7F09B.7070005@zedat.fu-berlin.de> <20070302152832.GA79187@lor.one-eyed-alien.net> In-Reply-To: <20070302152832.GA79187@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2702/Fri Mar 2 09:04:51 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-performance@freebsd.org, "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 18:51:01 -0000 On 03/02/07 09:28, Brooks Davis wrote: > On Fri, Mar 02, 2007 at 10:38:35AM +0100, O. Hartmann wrote: >> The last days I tried to figure out why some of my lab's FreeBSD boxes >> and also mine at home seem to be outperformed by some Linux setups >> around here and I saw something interesting. >> >> On my lab's FreeBSD 6.2/i386 box (ASUS P4P800, ICH5 with two SATA 150 >> ports, two SATA 300 drives attached) I copied big files (~ 5GB) from one >> drive to another while the box didn't do anything else than copying. I >> watched the copy process via 'systat -vmstat 1' and realized, that the >> value of 'KB/t' never go byond 128 (128kb buffer limit?). But more >> frustrating, I never got beyond 33 MB/s transfer rate although >> bonni/bonni++ told me both drives are capable doing much more (~75 MB/s >> each). >> At home, I use a FreeBSD 7.0-CURRENT box on an ASUS >> A8N32-SLI/nForce4-SLI based box, amd64 (no 32Bit compatibility). Two >> Hitachi T7K250 250 GB/SATA II drives build up a RAID 0 (nVidia >> MediaShield), and additionally there is a SAMSUNG Spinpoitn SP2004C >> attached to the controller. bonni results in 55 MB/s for the SP2004C >> alone and gives ~ 65 - 70 MB/s for the Hitachis, each and roughly 115 >> MB/s for the RAID 0. But copying from the single drive to the RAID 0 or >> from the RAID 0 to the single drive also reaches this oscure 33 MB/s >> boundary! >> >> In the first place I thought the older i386 hardware has some >> hard-limits, but we have several boxes of the exact same hardware around >> here and a wide spread Linux and Windows utilization and on those boxes >> equipted with more than one harddrive (PATA or SATA) the effective >> transfer rate shown up is about 50 - 65 MB/s as expected with copying a >> big 5G file from one drive to another. >> >> The hardwrae limit is completely nonsense when it comes to the AMD64 box >> with newer hardware. >> >> Before digging into this problem deeper with benchmarks, could anyone >> explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33 >> defaults, but on both boxes nForce4 and ICH5 controller are recognized >> and show up with SATA300 or SATA150 capabilities, respective)? May I >> have some knobs I'm not aware of to tune disk performance? >> >> I would appreciate any coments on that and if someone has some good >> ideas how to benchmark those subjects, please let me know. > > One thing to keep in mind is that it matters a lot were on the disk you > place the data due to the higher angular density of data at the outside > of the disk. The results you are seeing are close to consistant with > the kind of results I'd expect to see from writing at opposiste edges > of the disk. The 33MB/s is suspious ane may diserve investigation, but > make sure you are writing to the same part of the disk if you want to > compare disk IO rates. > > There's an example of IO rates on recent large SATA disks: > > http://storagereview.com/articles/200607/500_2.html > > Also, you should time the actual copy and do the math to verify that > vmstat is actually producing valid results. It's possible there's a bug > in vmstat or the underlying statistics it uses. I usually use gstat instead, but it might also be off (although my tests in the past have not proven that). Eric From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 19:29:40 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B621116A402; Fri, 2 Mar 2007 19:29:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3F613C474; Fri, 2 Mar 2007 19:29:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l22JTdN4061177; Fri, 2 Mar 2007 14:29:39 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id l22JTdrU091774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2007 14:29:39 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200703021929.l22JTdrU091774@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Mar 2007 14:27:41 -0500 To: "O. Hartmann" , freebsd-performance@freebsd.org, freebsd-questions@freebsd.org From: Mike Tancsa In-Reply-To: <45E7F09B.7070005@zedat.fu-berlin.de> References: <45E7F09B.7070005@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 19:29:40 -0000 At 04:38 AM 3/2/2007, O. Hartmann wrote: >The last days I tried to figure out why some of my lab's FreeBSD >boxes and also mine at home seem to be outperformed by some Linux >setups around here and I saw something interesting. > >On my lab's FreeBSD 6.2/i386 box (ASUS P4P800, ICH5 with two SATA >150 ports, two SATA 300 drives attached) I copied big files (~ 5GB) >from one drive to Something strange about your setup I would say. I just tried on a Segate SATA drive off an ICH5 chipset (plain old P IV 2.4Ghz). Do you have an option in your BIOS for "native mode" or compatibility mode for the SATA controller ? If so, try toggling that to native SATA mode [ns4]% iostat -c 1000 tty ad4 twed0 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 2 447 4.91 0 0.00 23.77 40 0.92 20 0 6 0 74 4 307 0.00 0 0.00 12.61 14 0.17 0 0 0 0 100 1 183 0.00 0 0.00 14.50 4 0.06 0 0 0 0 100 1 63 128.00 47 5.82 0.00 0 0.00 7 0 7 0 86 0 182 128.00 534 66.70 15.25 8 0.12 0 0 15 8 77 0 60 128.00 553 69.13 2.00 2 0.00 0 0 8 8 85 0 182 128.00 537 67.14 14.50 4 0.06 15 0 31 15 38 0 60 128.00 553 69.06 0.00 0 0.00 54 0 0 8 38 0 60 128.00 538 67.21 0.00 0 0.00 23 0 0 8 69 1 301 128.00 495 61.88 12.18 22 0.26 0 0 8 0 92 [ns4]# dd if=/dev/ad4 of=/dev/null bs=1024k ^C410+0 records in 410+0 records out 429916160 bytes transferred in 6.089321 secs (70601659 bytes/sec) [ns4]# [ns4]# atacontrol cap ad4 Protocol Serial ATA II device model ST3400833NS serial number 5NF25DTG firmware revision 3.AEH cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 781422768 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 65278/0xFEFE automatic acoustic management no no 0/0x00 254/0xFE [ns4]# >_______________________________________________ >freebsd-performance@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-performance >To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" From owner-freebsd-performance@FreeBSD.ORG Sat Mar 3 00:56:14 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B826816A400 for ; Sat, 3 Mar 2007 00:56:14 +0000 (UTC) (envelope-from amesbury@UMN.EDU) Received: from mta-a2.tc.umn.edu (mta-a2.tc.umn.edu [134.84.119.206]) by mx1.freebsd.org (Postfix) with ESMTP id 7E80213C491 for ; Sat, 3 Mar 2007 00:56:14 +0000 (UTC) (envelope-from amesbury@UMN.EDU) Received: from [160.94.247.212] (paulaner.oitsec.umn.edu [160.94.247.212]) by mta-a2.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 2 Mar 2007 17:56:05 -0600 (CST) X-Umn-Remote-Mta: [N] paulaner.oitsec.umn.edu [160.94.247.212] #+LO+TS+AU+HN Message-ID: <45E8B994.2010100@umn.edu> Date: Fri, 02 Mar 2007 17:56:04 -0600 From: Alan Amesbury User-Agent: Thunderbird 1.5.0.9 (X11/20061222) MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: <20070302120018.5830716A4A9@hub.freebsd.org> In-Reply-To: <20070302120018.5830716A4A9@hub.freebsd.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2007 00:56:14 -0000 O. Hartmann" wrote: > If SYNC is default how can you explain this: > > [12:58]root@hater:~# mount > /dev/ad4s3a on / (ufs, local, synchronous) > devfs on /dev (devfs, local) > /dev/ad4s3d on /tmp (ufs, local, soft-updates) > /dev/ad4s3f on /usr (ufs, local, soft-updates) > /dev/ad4s3e on /var (ufs, local, soft-updates) > > [13:00]root@hater:~# cat /etc/fstab > # Device Mountpoint FStype Options Dump > Pass# > /dev/ad4s3b none swap sw 0 0 > /dev/ad4s3a / ufs rw,sync 1 1 > /dev/ad4s3d /tmp ufs rw 2 2 > /dev/ad4s3f /usr ufs rw 2 2 > /dev/ad4s3e /var ufs rw 2 2 > > And this is only because I manually add *sync* to my /etc/fstab. > > E.g if sync is default why mount do not report that my /dev/ad4s3f on > /usr is mounted synchronous? [snip] No, the default with softupdates disabled is synchronous, not asynchronous under FreeBSD. There was a thread on this years ago (back around 3.5-RELEASE?) where this was discussed in detail. (I'm too lazy to look for it.) The discussion centered around the Linux ext2 working faster than UFS/FFS and it was exactly because ext2 file systems were mounted async by default and UFS/FFS sync by default. Looking at /usr/include/sys/mount.h, I see that there are two flags defined: MNT_SYNCHRONOUS and MNT_ASYNC. I'm not sure why both flags exist, but suspect the former was added so you could mount UFS/FFS/UFS2 filesystems that had soft updates enabled in synchronous mode without having to umount the filesystem, use tunefs(8)'s "-n" flag to enable/disable soft updates, then remount the filesystem with the appropriate flag(s). To return to your original questions, though..... I'm not sure why KB/t doesn't exceed 128, but suspect that you're right about it being a buffer limit of some sort. No idea where, though, without digging through some source. My guess is that the answer is buried somewhere in the ATA DMA bus code, but that's pure speculation. I'm unsure what would cause the slowdown you mention, too. If it were PATA, I'd immediately suspect some sort of legacy device being present, e.g., an older CD-ROM drive or something. However, that's not a concern in the SATA world, and connections are (I thought) point-to-point. Perhaps it's an interrupt sharing problem? Do you have a legacy PATA controller enabled and sharing resources with your SATA controller(s)? What does 'dmesg' show for device identification, in particular which device is on which atan-[master|slave] connection? I'd be careful about running things like 'vmstat' or 'systat' with intervals shorter than five seconds, though, as some of those tools have historically had counters that didn't update meaningfully in intervals shorter than that. There's also the question of jitter, noise, whatever. Also, if you want to benchmark the filesystem code, try running tests against a memory-backed filesystem (but one that doesn't swap!) to see how well they perform. Good luck with your testing! -- Alan Amesbury University of Minnesota From owner-freebsd-performance@FreeBSD.ORG Sat Mar 3 07:14:25 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68B1E16A403; Sat, 3 Mar 2007 07:14:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 248FD13C467; Sat, 3 Mar 2007 07:14:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 792D33280D8; Sat, 3 Mar 2007 18:14:23 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 4350F8C09; Sat, 3 Mar 2007 18:14:22 +1100 (EST) Date: Sat, 3 Mar 2007 18:14:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Brooks Davis In-Reply-To: <20070302152832.GA79187@lor.one-eyed-alien.net> Message-ID: <20070303174120.F13432@delplex.bde.org> References: <45E7F09B.7070005@zedat.fu-berlin.de> <20070302152832.GA79187@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-performance@freebsd.org, "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2007 07:14:25 -0000 On Fri, 2 Mar 2007, Brooks Davis wrote: > Also, you should time the actual copy and do the math to verify that > vmstat is actually producing valid results. It's possible there's a bug > in vmstat or the underlying statistics it uses. There is certainly a bug in the underlying statistics. For ATA disks, at least with the ata driver, the maximum transfer size in DMA mode is 64K, so any reports of a block size of 128K for SATA disks are wrong. The block size of 128K reported by vmstat is actually a virtual size. For most or types of disks, the GEOM layer virtualizes the physical maximum size MAXPHYS = 128K so that layers above GEOM including statistics gathering and file systems cannot see the physical size. For writing large files, this normally confuses ffs and vfs clustering into producing contiguous writes of 128K. This is good for efficiency, but it is not what the hardware sees or what you want for statistics. The contiguous writes of 128K get split up into 2 sequential writes of 64K. However, 64K is more than large enough for efficiency, so the bug in the underlying statistics doesn't matter, at least if vmstat reports only 128K blocks. If it reported 64K-blocks then you would have to worry about the contiguous block sizes being a mixture of 128K and much smaller blocks, with the much smaller blocks (actually, more the seeks across gaps to get to the smaller blocks) being very inefficient. Bruce From owner-freebsd-performance@FreeBSD.ORG Sat Mar 3 10:09:47 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 834CC16A405 for ; Sat, 3 Mar 2007 10:09:47 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 3DEC113C491 for ; Sat, 3 Mar 2007 10:09:47 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5F2C9.dip.t-dialin.net [84.165.242.201]) by redbull.bpaserver.net (Postfix) with ESMTP id BB0AA2E1AE; Sat, 3 Mar 2007 11:09:43 +0100 (CET) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 000325B4817; Sat, 3 Mar 2007 11:09:40 +0100 (CET) Date: Sat, 3 Mar 2007 11:09:40 +0100 From: Alexander Leidinger To: Alan Amesbury Message-ID: <20070303110940.32893388@Magellan.Leidinger.net> In-Reply-To: <45E8B994.2010100@umn.edu> References: <20070302120018.5830716A4A9@hub.freebsd.org> <45E8B994.2010100@umn.edu> X-Mailer: Claws Mail 2.8.0 (GTK+ 2.10.9; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 8, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-performance@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2007 10:09:47 -0000 Quoting Alan Amesbury (Fri, 02 Mar 2007 17:56:04 -0600): > Looking at /usr/include/sys/mount.h, I see that there are two flags > defined: MNT_SYNCHRONOUS and MNT_ASYNC. I'm not sure why both flags > exist, but suspect the former was added so you could mount UFS/FFS/UFS2 > filesystems that had soft updates enabled in synchronous mode without > having to umount the filesystem, use tunefs(8)'s "-n" flag to > enable/disable soft updates, then remount the filesystem with the > appropriate flag(s). In FreeBSD we have 3 types, not 2. We have "sync", "noasync" (default) and "async". With noasync the meta-data is written in sync mode and the data is written in async mode. For async the complete IO is done asynchronous (the meta-data too). And for sync the complete IO is synchronous. mount(8) tells this with some more words. Bye, Alexander. -- As a math atheist, I should be excused from this. -- Calvin http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-performance@FreeBSD.ORG Sat Mar 3 11:03:49 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 707A216A400; Sat, 3 Mar 2007 11:03:49 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from mail.freebsd-corp-net-guide.com (mail.web-strider.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3554D13C481; Sat, 3 Mar 2007 11:03:48 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from coolf89ea26645 (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.13.8/8.13.8) with SMTP id l23B3dMb084287; Sat, 3 Mar 2007 03:03:44 -0800 (PST) (envelope-from tedm@toybox.placo.com) Message-ID: <002d01c75d83$7b349110$3c01a8c0@coolf89ea26645> From: "Ted Mittelstaedt" To: "Cheffo" References: <45E7F09B.7070005@zedat.fu-berlin.de><00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> <45E80CC5.8080607@FreeBSD-BG.org> Date: Sat, 3 Mar 2007 03:02:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.freebsd-corp-net-guide.com [65.75.192.90]); Sat, 03 Mar 2007 03:03:45 -0800 (PST) Cc: freebsd-performance@freebsd.org, "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2007 11:03:49 -0000 ----- Original Message ----- From: "Cheffo" To: "Ted Mittelstaedt" Cc: ; "O. Hartmann" ; Sent: Friday, March 02, 2007 3:38 AM Subject: Re: (S)ATA performance in FBSD 6.2/7.0 > Hi, > > > I think the problem is that the benchmark runs with small files and most > files are in cache that's why it shows higher speeds I think the problem is O Hartmann (the OP) has proven by his lack of followup that he was just trolling. Kind of what I guessed yesterday. Ted