From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932666AbcHKDMH (ORCPT ); Wed, 10 Aug 2016 23:12:07 -0400 Received: from ipmail05.adl6.internode.on.net ([150.101.137.143]:24359 "EHLO ipmail05.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932212AbcHKDMD (ORCPT ); Wed, 10 Aug 2016 23:12:03 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2C0BACF6qtXIAI1LHlXBoNFVnykKoxiiB6BfSSFcwQCAoFiORQBAQEBAQEBBgEBAQEBAThAhF8BBQEBOBwYCxAIAxgJJQ8FEwERAwcaE4gwD8I3AQEBAQEFAQEBAR4FHoVEhRWBOQGBJYFThWkFmTyGHoVCgyqPTYw0g3gegkgND4FeKjKHUQEBAQ Date: Thu, 11 Aug 2016 13:05:35 +1000 From: Dave Chinner To: Ye Xiaolong Cc: "Huang, Ying" , Linus Torvalds , LKML , Bob Peterson , Wu Fengguang , LKP , Christoph Hellwig Subject: Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression Message-ID: <20160811030534.GV16044@dastard> References: <20160810230840.GS16044@dastard> <87eg5w18iu.fsf@yhuang-mobile.sh.intel.com> <87a8gk17x7.fsf@yhuang-mobile.sh.intel.com> <8760r816wf.fsf@yhuang-mobile.sh.intel.com> <20160811011612.GT16044@dastard> <20160811013223.GU16044@dastard> <20160811023659.GA2896@yexl-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160811023659.GA2896@yexl-desktop> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 11, 2016 at 10:36:59AM +0800, Ye Xiaolong wrote: > On 08/11, Dave Chinner wrote: > >On Thu, Aug 11, 2016 at 11:16:12AM +1000, Dave Chinner wrote: > >> I need to see these events: > >> > >> xfs_file* > >> xfs_iomap* > >> xfs_get_block* > >> > >> For both kernels. An example trace from 4.8-rc1 running the command > >> `xfs_io -f -c 'pwrite 0 512k -b 128k' /mnt/scratch/fooey doing an > >> overwrite and extend of the existing file ends up looking like: > >> > >> $ sudo trace-cmd start -e xfs_iomap\* -e xfs_file\* -e xfs_get_blocks\* > >> $ sudo cat /sys/kernel/tracing/trace_pipe > >> <...>-2946 [001] .... 253971.750304: xfs_file_ioctl: dev 253:32 ino 0x84 > >> xfs_io-2946 [001] .... 253971.750938: xfs_file_buffered_write: dev 253:32 ino 0x84 size 0x40000 offset 0x0 count 0x20000 > >> xfs_io-2946 [001] .... 253971.750961: xfs_iomap_found: dev 253:32 ino 0x84 size 0x40000 offset 0x0 count 131072 type invalid startoff 0x0 startblock 24 blockcount 0x60 > >> xfs_io-2946 [001] .... 253971.751114: xfs_file_buffered_write: dev 253:32 ino 0x84 size 0x40000 offset 0x20000 count 0x20000 > >> xfs_io-2946 [001] .... 253971.751128: xfs_iomap_found: dev 253:32 ino 0x84 size 0x40000 offset 0x20000 count 131072 type invalid startoff 0x0 startblock 24 blockcount 0x60 > >> xfs_io-2946 [001] .... 253971.751234: xfs_file_buffered_write: dev 253:32 ino 0x84 size 0x40000 offset 0x40000 count 0x20000 > >> xfs_io-2946 [001] .... 253971.751236: xfs_iomap_found: dev 253:32 ino 0x84 size 0x40000 offset 0x40000 count 131072 type invalid startoff 0x0 startblock 24 blockcount 0x60 > >> xfs_io-2946 [001] .... 253971.751381: xfs_file_buffered_write: dev 253:32 ino 0x84 size 0x40000 offset 0x60000 count 0x20000 > >> xfs_io-2946 [001] .... 253971.751415: xfs_iomap_prealloc_size: dev 253:32 ino 0x84 prealloc blocks 128 shift 0 m_writeio_blocks 16 > >> xfs_io-2946 [001] .... 253971.751425: xfs_iomap_alloc: dev 253:32 ino 0x84 size 0x40000 offset 0x60000 count 131072 type invalid startoff 0x60 startblock -1 blockcount 0x90 > >> > >> That's the output I need for the complete test - you'll need to use > >> a better recording mechanism that this (e.g. trace-cmd record, > >> trace-cmd report) because it will generate a lot of events. Compress > >> the two report files (they'll be large) and send them to me offlist. > > > >Can you also send me the output of xfs_info on the filesystem you > >are testing? > > Hi, Dave > > Here is the xfs_info output: > > # xfs_info /fs/ram0/ > meta-data=/dev/ram0 isize=256 agcount=4, agsize=3145728 blks > = sectsz=4096 attr=2, projid32bit=1 > = crc=0 finobt=0 > data = bsize=4096 blocks=12582912, imaxpct=25 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 ftype=0 > log =internal bsize=4096 blocks=6144, version=2 > = sectsz=4096 sunit=1 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 OK, nothing unusual there. One thing that I did just think of - how close to ENOSPC does this test get? i.e. are we hitting the "we're almost out of free space" slow paths on this test? Cheers, dave. > > Thanks, > Xiaolong > > > >Cheers, > > > >Dave. > >-- > >Dave Chinner > >david@fromorbit.com > >_______________________________________________ > >LKP mailing list > >LKP@lists.01.org > >https://lists.01.org/mailman/listinfo/lkp > -- Dave Chinner david@fromorbit.com From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7181432810526773299==" MIME-Version: 1.0 From: Dave Chinner To: lkp@lists.01.org Subject: Re: [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression Date: Thu, 11 Aug 2016 13:05:35 +1000 Message-ID: <20160811030534.GV16044@dastard> In-Reply-To: <20160811023659.GA2896@yexl-desktop> List-Id: --===============7181432810526773299== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Aug 11, 2016 at 10:36:59AM +0800, Ye Xiaolong wrote: > On 08/11, Dave Chinner wrote: > >On Thu, Aug 11, 2016 at 11:16:12AM +1000, Dave Chinner wrote: > >> I need to see these events: > >> = > >> xfs_file* > >> xfs_iomap* > >> xfs_get_block* > >> = > >> For both kernels. An example trace from 4.8-rc1 running the command > >> `xfs_io -f -c 'pwrite 0 512k -b 128k' /mnt/scratch/fooey doing an > >> overwrite and extend of the existing file ends up looking like: > >> = > >> $ sudo trace-cmd start -e xfs_iomap\* -e xfs_file\* -e xfs_get_blocks\* > >> $ sudo cat /sys/kernel/tracing/trace_pipe > >> <...>-2946 [001] .... 253971.750304: xfs_file_ioctl: dev 2= 53:32 ino 0x84 > >> xfs_io-2946 [001] .... 253971.750938: xfs_file_buffered_wri= te: dev 253:32 ino 0x84 size 0x40000 offset 0x0 count 0x20000 > >> xfs_io-2946 [001] .... 253971.750961: xfs_iomap_found: dev = 253:32 ino 0x84 size 0x40000 offset 0x0 count 131072 type invalid startoff = 0x0 startblock 24 blockcount 0x60 > >> xfs_io-2946 [001] .... 253971.751114: xfs_file_buffered_wri= te: dev 253:32 ino 0x84 size 0x40000 offset 0x20000 count 0x20000 > >> xfs_io-2946 [001] .... 253971.751128: xfs_iomap_found: dev = 253:32 ino 0x84 size 0x40000 offset 0x20000 count 131072 type invalid start= off 0x0 startblock 24 blockcount 0x60 > >> xfs_io-2946 [001] .... 253971.751234: xfs_file_buffered_wri= te: dev 253:32 ino 0x84 size 0x40000 offset 0x40000 count 0x20000 > >> xfs_io-2946 [001] .... 253971.751236: xfs_iomap_found: dev = 253:32 ino 0x84 size 0x40000 offset 0x40000 count 131072 type invalid start= off 0x0 startblock 24 blockcount 0x60 > >> xfs_io-2946 [001] .... 253971.751381: xfs_file_buffered_wri= te: dev 253:32 ino 0x84 size 0x40000 offset 0x60000 count 0x20000 > >> xfs_io-2946 [001] .... 253971.751415: xfs_iomap_prealloc_si= ze: dev 253:32 ino 0x84 prealloc blocks 128 shift 0 m_writeio_blocks 16 > >> xfs_io-2946 [001] .... 253971.751425: xfs_iomap_alloc: dev = 253:32 ino 0x84 size 0x40000 offset 0x60000 count 131072 type invalid start= off 0x60 startblock -1 blockcount 0x90 > >> = > >> That's the output I need for the complete test - you'll need to use > >> a better recording mechanism that this (e.g. trace-cmd record, > >> trace-cmd report) because it will generate a lot of events. Compress > >> the two report files (they'll be large) and send them to me offlist. > > > >Can you also send me the output of xfs_info on the filesystem you > >are testing? > = > Hi, Dave > = > Here is the xfs_info output: > = > # xfs_info /fs/ram0/ > meta-data=3D/dev/ram0 isize=3D256 agcount=3D4, agsize=3D3= 145728 blks > =3D sectsz=3D4096 attr=3D2, projid32bit= =3D1 > =3D crc=3D0 finobt=3D0 > data =3D bsize=3D4096 blocks=3D12582912, imax= pct=3D25 > =3D sunit=3D0 swidth=3D0 blks > naming =3Dversion 2 bsize=3D4096 ascii-ci=3D0 ftype=3D0 > log =3Dinternal bsize=3D4096 blocks=3D6144, version= =3D2 > =3D sectsz=3D4096 sunit=3D1 blks, lazy-co= unt=3D1 > realtime =3Dnone extsz=3D4096 blocks=3D0, rtextents= =3D0 OK, nothing unusual there. One thing that I did just think of - how close to ENOSPC does this test get? i.e. are we hitting the "we're almost out of free space" slow paths on this test? Cheers, dave. > = > Thanks, > Xiaolong > > > >Cheers, > > > >Dave. > >-- = > >Dave Chinner > >david(a)fromorbit.com > >_______________________________________________ > >LKP mailing list > >LKP(a)lists.01.org > >https://lists.01.org/mailman/listinfo/lkp > = -- = Dave Chinner david(a)fromorbit.com --===============7181432810526773299==--