Date: Sun, 6 Jun 2010 02:21:45 +0200 From: Attilio Rao <attilio@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Matthew Jacob <mj@feral.com> Subject: Re: sysbench / fileio - Linux vs. FreeBSD Message-ID: <AANLkTikalerFWLJncPOEDFz6yGN74bUju_H_JKvFrRwT@mail.gmail.com> 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> <AANLkTikZY65hJO7gLldYSVn7vts84fou64kipWsH0y0i@mail.gmail.com> <20100605175123.GY83316@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/6/5 Kostik Belousov <kostikbel@gmail.com> > > On Sat, Jun 05, 2010 at 07:41:23PM +0200, Attilio Rao wrote: > > 2010/6/5 Matthew Jacob <mj@feral.com> > > > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikalerFWLJncPOEDFz6yGN74bUju_H_JKvFrRwT>