linux-kernel - Re: [MMTests] IO metadata on XFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Jul 2012 14:30:57 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	Dave Chinner <david@...morbit.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, xfs@....sgi.com
Subject: Re: [MMTests] IO metadata on XFS

On Mon, Jul 02, 2012 at 09:54:58AM +1000, Dave Chinner wrote:
> On Fri, Jun 29, 2012 at 12:25:06PM +0100, Mel Gorman wrote:
> > Configuration:	global-dhp__io-metadata-xfs
> > Benchmarks:	dbench3, fsmark-single, fsmark-threaded
> > 
> > Summary
> > =======
> > Most of the figures look good and in general there has been consistent good
> > performance from XFS. However, fsmark-single is showing a severe performance
> > dip in a few cases somewhere between 3.1 and 3.4. fs-mark running a single
> > thread took a particularly bad dive in 3.4 for two machines that is worth
> > examining closer.
> 
> That will be caused by the fact we changed all the metadata updates
> to be logged, which means a transaction every time .dirty_inode is
> called.
> 

Ok.

> This should mostly go away when XFS is converted to use .update_time
> rather than .dirty_inode to only issue transactions when the VFS
> updates the atime rather than every .dirty_inode call...
> 

Sound. I'll keep an eye out for it in the future.  If you want to
use the same test configuration then be sure you set the partition
configuration correctly. For example, these are the values I used for
config-global-dhp__io-metadata configuration file.

export TESTDISK_PARTITION=/dev/sda6
export TESTDISK_FILESYSTEM=xfs
export TESTDISK_MKFS_PARAM="-f -d agcount=8"
export TESTDISK_MOUNT_ARGS=inode64,delaylog,logbsize=262144,nobarrier

> > Unfortunately it is harder to easy conclusions as the
> > gains/losses are not consistent between machines which may be related to
> > the available number of CPU threads.
> 
> It increases the CPU overhead (dirty_inode can be called up to 4
> times per write(2) call, IIRC), so with limited numbers of
> threads/limited CPU power it will result in lower performance. Where
> you have lots of CPU power, there will be little difference in
> performance...
> 

Thanks for that clarification.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/