From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH] fs: Make sync_file_range(2) use WB_SYNC_NONE writeback Date: Fri, 6 Nov 2015 21:43:42 +0100 Message-ID: <20151106204342.GA2793@quack.suse.cz> References: <1445714897-26342-1-git-send-email-jack@suse.com> <20151028093040.GG29811@alap3.anarazel.de> <20151028141852.GA11575@quack.suse.cz> <20151106130612.GA21749@awork2.anarazel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , Jan Kara , linux-fsdevel@vger.kernel.org, Andrew Morton , Al Viro To: Andres Freund Return-path: Received: from mx2.suse.de ([195.135.220.15]:47707 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030793AbbKFUno (ORCPT ); Fri, 6 Nov 2015 15:43:44 -0500 Content-Disposition: inline In-Reply-To: <20151106130612.GA21749@awork2.anarazel.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello, On Fri 06-11-15 14:06:12, Andres Freund wrote: > On 2015-10-28 15:18:52 +0100, Jan Kara wrote: > > On Wed 28-10-15 10:30:40, Andres Freund wrote: > > > On 2015-10-24 21:28:17 +0200, Jan Kara wrote: > > > Thanks. Would scheduling a comparative benchmark of this be helpful > > > pushing htis forward ? Would probably only be early next week, I'm at > > > the european postgresql conference right now. > > > > If you could run it, it would be nice. Thanks! > > Sorry that it took longer. Had some $work deadline making a surprise > attack (sneaky bastard) and then difficulity getting time on a bigger > box. Hence I only have numbers from a single SSD drive (840 EVO 1TB) > laptop (16GB RAM, i7-4800MQ), with nothing else running. > > I've compared 4.3.0-andres-07965-gd1e41ff, with/without the patch > applied. Best of three results: > > Before: > transaction type: TPC-B (sort of) > scaling factor: 300 > query mode: prepared > number of clients: 48 > number of threads: 48 > duration: 1000 s > number of transactions actually processed: 7873859 > latency average: 6.094 ms > latency stddev: 35.376 ms > tps = 7871.887045 (including connections establishing) > tps = 7872.135871 (excluding connections establishing) > > > After: > transaction type: TPC-B (sort of) > scaling factor: 300 > query mode: prepared > number of clients: 48 > number of threads: 48 > duration: 1000 s > number of transactions actually processed: 9370637 > latency average: 5.119 ms > latency stddev: 24.423 ms > tps = 9369.212486 (including connections establishing) > tps = 9369.725595 (excluding connections establishing) > > Pretty tidy improvement I'd say. > > Feel free to add a > Tested-By: Andres Freund > > There's still quite some further room of improvement. E.g. some > quite massive peaks in latency, which don't coincide with background > work in postgres: > progress: 869.0 s, 9971.2 tps, lat 4.828 ms stddev 6.201 > progress: 870.0 s, 8196.4 tps, lat 4.632 ms stddev 6.774 > progress: 871.0 s, 497.0 tps, lat 89.598 ms stddev 308.398 > progress: 872.0 s, 10360.6 tps, lat 5.917 ms stddev 40.041 > progress: 873.0 s, 7005.5 tps, lat 6.743 ms stddev 21.985 > > Without controlling writeout via sync_file_range(), we frequently can > see stalls in the tens of seconds on busy machines though... So this is > still much better ;) Thanks for doing the test and I'm happy it improved your results. Andrew has already picked up the patch into his tree so it will eventually hit the upstream kernel (not sure if for 4.4 already but for 4.5 certainly). Honza -- Jan Kara SUSE Labs, CR