From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 5312E7CB9 for ; Mon, 22 Feb 2016 02:54:20 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 23D8D30408D for ; Mon, 22 Feb 2016 00:54:14 -0800 (PST) Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) by cuda.sgi.com with ESMTP id SDxXsqire38ps5vo (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 22 Feb 2016 00:54:11 -0800 (PST) Date: Mon, 22 Feb 2016 09:54:09 +0100 From: Christoph Hellwig Subject: Re: [lkp] [xfs] fbcc025613: -5.6% fsmark.files_per_sec Message-ID: <20160222085409.GA19493@lst.de> References: <87vb5lqunb.fsf@yhuang-dev.intel.com> <20160219064932.GX14668@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160219064932.GX14668@dastard> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Dave Chinner Cc: kernel test robot , LKML , xfs@oss.sgi.com, Dave Chinner , lkp@01.org, Christoph Hellwig On Fri, Feb 19, 2016 at 05:49:32PM +1100, Dave Chinner wrote: > That doesn't really seem right. The writeback should be done as a > single ioend, with a single completion, with a single setsize > transaction, adn then all the pages are marked clean sequentially. > The above behaviour implies we are ending up doing something like: > > fsync proc io completion > wait on page 0 > end page 0 writeback > wake up page 0 > wait on page 1 > end page 1 writeback > wake up page 1 > wait on page 2 > end page 2 writeback > wake up page 2 > > Though in slightly larger batches than a single page (10 wakeups a > file, so batches of around 100 pages per wakeup?). i.e. the fsync > IO wait appears to be racing with IO completion marking pages as > done. I simply cannot see how the above change would cause that, as > it was simply a change in the IO submission code that doesn't affect > overall size or shape of the IOs being submitted. Could this be the lack of blk plugs, which will cause us to complete too early? _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4219987168687400485==" MIME-Version: 1.0 From: Christoph Hellwig To: lkp@lists.01.org Subject: Re: [xfs] fbcc025613: -5.6% fsmark.files_per_sec Date: Mon, 22 Feb 2016 09:54:09 +0100 Message-ID: <20160222085409.GA19493@lst.de> In-Reply-To: <20160219064932.GX14668@dastard> List-Id: --===============4219987168687400485== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, Feb 19, 2016 at 05:49:32PM +1100, Dave Chinner wrote: > That doesn't really seem right. The writeback should be done as a > single ioend, with a single completion, with a single setsize > transaction, adn then all the pages are marked clean sequentially. > The above behaviour implies we are ending up doing something like: > = > fsync proc io completion > wait on page 0 > end page 0 writeback > wake up page 0 > wait on page 1 > end page 1 writeback > wake up page 1 > wait on page 2 > end page 2 writeback > wake up page 2 > = > Though in slightly larger batches than a single page (10 wakeups a > file, so batches of around 100 pages per wakeup?). i.e. the fsync > IO wait appears to be racing with IO completion marking pages as > done. I simply cannot see how the above change would cause that, as > it was simply a change in the IO submission code that doesn't affect > overall size or shape of the IOs being submitted. Could this be the lack of blk plugs, which will cause us to complete too early? --===============4219987168687400485==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753223AbcBVIyM (ORCPT ); Mon, 22 Feb 2016 03:54:12 -0500 Received: from verein.lst.de ([213.95.11.211]:60674 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751797AbcBVIyL (ORCPT ); Mon, 22 Feb 2016 03:54:11 -0500 Date: Mon, 22 Feb 2016 09:54:09 +0100 From: Christoph Hellwig To: Dave Chinner Cc: kernel test robot , Dave Chinner , lkp@01.org, LKML , Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [lkp] [xfs] fbcc025613: -5.6% fsmark.files_per_sec Message-ID: <20160222085409.GA19493@lst.de> References: <87vb5lqunb.fsf@yhuang-dev.intel.com> <20160219064932.GX14668@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160219064932.GX14668@dastard> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 19, 2016 at 05:49:32PM +1100, Dave Chinner wrote: > That doesn't really seem right. The writeback should be done as a > single ioend, with a single completion, with a single setsize > transaction, adn then all the pages are marked clean sequentially. > The above behaviour implies we are ending up doing something like: > > fsync proc io completion > wait on page 0 > end page 0 writeback > wake up page 0 > wait on page 1 > end page 1 writeback > wake up page 1 > wait on page 2 > end page 2 writeback > wake up page 2 > > Though in slightly larger batches than a single page (10 wakeups a > file, so batches of around 100 pages per wakeup?). i.e. the fsync > IO wait appears to be racing with IO completion marking pages as > done. I simply cannot see how the above change would cause that, as > it was simply a change in the IO submission code that doesn't affect > overall size or shape of the IOs being submitted. Could this be the lack of blk plugs, which will cause us to complete too early?