From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 6 00:21:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B541E106566C for ; Sun, 6 Jun 2010 00:21:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5CFDE8FC22 for ; Sun, 6 Jun 2010 00:21:46 +0000 (UTC) Received: by vws18 with SMTP id 18so970142vws.13 for ; Sat, 05 Jun 2010 17:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qpbn9Qv9FXjrL1CTvyo871ji4pigx1TQ+Be8EePLOV4=; b=EGKER+cR8HlmBv8WQqqXsBV3gYvTkOrpdP/hq3brx+0xzyJsJQ+SukeKhE+XQtTtqI Mdgf7gS28tA9yjQ4YvogwV1DDDSbbDQvT8X7p1dZz9Nf/WWPM39DyshYAum4OaLorGbr GhBUQcA1S1gq5nSeaZOnu+TXSps4eCi5cJd2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ofHB/iscTGHc9/QEfJYeoJXKpbUnyWWpqzielfLK7BJy3oosBJp0tQKhPoHn8D/eWv RugCxVWToDeeYQwk5nm3lM3+jLGYeGqxwUgXhCZ7Y3I6z8/PGaMJRLx+r5v+fmfcJqxd du35G3lcn9qIxwGysVokNYHr82Pqqxez9eCJc= MIME-Version: 1.0 Received: by 10.224.86.200 with SMTP id t8mr6062702qal.50.1275783705330; Sat, 05 Jun 2010 17:21:45 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.183.213 with HTTP; Sat, 5 Jun 2010 17:21:45 -0700 (PDT) In-Reply-To: <20100605175123.GY83316@deviant.kiev.zoral.com.ua> References: <4C09932B.6040808@wooh.hu> <201006050236.17697.bruce@cran.org.uk> <4C09FC43.8070804@wooh.hu> <4C0A7F2F.3030105@elischer.org> <4C0A816A.9040403@feral.com> <20100605175123.GY83316@deviant.kiev.zoral.com.ua> Date: Sun, 6 Jun 2010 02:21:45 +0200 X-Google-Sender-Auth: bggLgAtXACRcNkfe2uaVi_nIo74 Message-ID: From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Matthew Jacob Subject: Re: sysbench / fileio - Linux vs. FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2010 00:21:46 -0000 2010/6/5 Kostik Belousov > > On Sat, Jun 05, 2010 at 07:41:23PM +0200, Attilio Rao wrote: > > 2010/6/5 Matthew Jacob > > > > > > All of these tests have been apples vs. oranges for years. > > > > > > The following seems to be true, though: > > > > > > a) FreeBSD sequential write performance in UFS has always been less t= han optimal. > > > > > > b) Linux sequential write performance in just about any filesystem ha= s always been "impressive". But that "impressive" has come at some not so o= bvious costs. First of all, Linux is probably the most aggressive cluster/w= rite-behind OS I've even seen. You can suck down all available memory with = writebehind using dd. This means that some stats are "impressive", and othe= rs are "painful". A desktop that becomes completely unresponsive while you'= re doing this dd is one personal outcome. > > > > > > Also, you have to be careful what you're asking for in comparing the = two platforms, or any platforms for that matter. What do you want to optimi= ze for? Apparent responsiveness as a desktop? A specific workload (nfs, cif= s) that completes N quatloos per fortnight? > > > > Besides anything, I'm much more concerned about the loss of > > performance within FreeBSD itself. I wouldn't expect a so high > > pessimization when the number of threads increases (without > > considering the big performance loss with the 8k blocksize, pretty > > much reproducible). I'm trying to drive, privately, the tester to > > pmc/lock profiling analysis in order to start collecting some useful > > datas. > Are the benchmarks create threads that write to the same file ? > If yes, then this behaviour is well understood. Actually I still don't know as I just sent an e-mail to the tester and he didn't followup still. However I'm not entirely sure this is a full bottleneck which may be reconduit to missing of byte-range locking. I want to dig more and better understand what's going on exactly. Attilio -- Peace can only be achieved by understanding - A. Einstein