From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Phillips Subject: Re: Tux3 Report: How fast can we =?iso-8859-1?Q?fsync=3F?= Date: Thu, 30 Apr 2015 03:59:08 -0700 Message-ID: <7322d870-e627-4ba4-91b4-bcb38ad8d015@phunq.net> References: <8f886f13-6550-4322-95be-93244ae61045@phunq.net> <1430274071.3363.4.camel@gmail.com> <1906f271-aa23-404b-9776-a4e2bce0c6aa@phunq.net> <1430289213.3693.3.camel@gmail.com> <1430325763.19371.41.camel@gmail.com> <1430365857.3180.18.camel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: , , , Theodore Ts'o , OGAWA Hirofumi To: Mike Galbraith Return-path: In-Reply-To: <1430365857.3180.18.camel@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wednesday, April 29, 2015 8:50:57 PM PDT, Mike Galbraith wrote: > On Wed, 2015-04-29 at 13:40 -0700, Daniel Phillips wrote: >> >> That order of magnitude latency difference is striking. It sounds >> good, but what does it mean? I see a smaller difference here, maybe >> because of running under KVM. > > That max_latency thing is flush. Right, it is just the max run time of all operations, including flush (dbench's name for fsync I think) which would most probably be the longest running one. I would like to know how we manage to pull that off. Now that you mention it, I see a factor of two or so latency win here, not the order of magnitude that you saw. Maybe KVM introduces some fuzz for me. I checked whether fsync = sync is the reason, and no. Well, that goes on the back burner, we will no doubt figure it out in due course. Regards, Daniel