From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [RFC, PATCH 0/12] xfs: compound buffers for directory blocks
Date: Wed, 7 Dec 2011 20:23:20 +1100 [thread overview]
Message-ID: <20111207092320.GA14273@dastard> (raw)
In-Reply-To: <20111207063508.GA13931@infradead.org>
On Wed, Dec 07, 2011 at 01:35:08AM -0500, Christoph Hellwig wrote:
> On Wed, Dec 07, 2011 at 05:18:11PM +1100, Dave Chinner wrote:
> > The series passes xfstests on 4k/4k, 4k/512b, 64k/4k and 64k/512b
> > (dirblksz/fsblksz) configurations without any new regressions, and
> > survives 100 million inode fs_mark benchmarks on a 17TB filesystem
> > using 4k/4k, 64k/512b and 64k/512b configurations.
>
> Do you have any benchmark numbers showing performance improvements
> for the large directory block case?
I haven't run real comparisons yet (it hasn't been working for long
enough for me to do so), but I suspect that the gains are lost
in the amount of CPU overhead the buffer formatting code is
consuming - it's around 40-50% of the entire CPU time on the
parallel create tests:
+ 13.10% [kernel] [k] memcpy
+ 7.94% [kernel] [k] xfs_next_bit
+ 7.63% [kernel] [k] xfs_buf_find_irec.isra.11
+ 5.86% [kernel] [k] xfs_buf_offset
+ 4.36% [kernel] [k] xfs_buf_item_format_segment
+ 4.11% [kernel] [k] xfs_buf_item_size_segment.isra.0
That's all cpu usage under the transaction commit path.
Basically I'm getting 100-110k files/s with 4k directory sizes, and
70-80k files/s with 64k dirs for the same workload consuming the
same amount of roughly the same CPU time. Killing the buffer logging
overhead (which barely registers on the 4k directory block size)
looks like it will now bring parity to large block size directory
performance compared to 4k block size performance because the amount
written to the log (~30MB/s) is identical for both configurations...
It might cwbe as simple as checking the hamming weight of the dirty
bitmap, and if it is over a certain amount just log the buffer in
it's entirity, skipping the bitmap based dirty region processing
altogether...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-12-07 9:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-07 6:18 [RFC, PATCH 0/12] xfs: compound buffers for directory blocks Dave Chinner
2011-12-07 6:18 ` [PATCH 01/12] xfs: remove remaining scraps of struct xfs_iomap Dave Chinner
2011-12-08 16:02 ` Christoph Hellwig
2011-12-07 6:18 ` [PATCH 02/12] xfs: clean up buffer get/read call API Dave Chinner
2011-12-08 16:07 ` Christoph Hellwig
2011-12-07 6:18 ` [PATCH 03/12] xfs: introduce a compound buffer construct Dave Chinner
2011-12-17 23:11 ` Christoph Hellwig
2011-12-07 6:18 ` [PATCH 04/12] xfs: add compound buffer get and read interfaces Dave Chinner
2011-12-17 23:14 ` Christoph Hellwig
2011-12-07 6:18 ` [PATCH 05/12] xfs: add irec interfaces to xfs_trans_buf_get/read Dave Chinner
2011-12-07 6:18 ` [PATCH 06/12] xfs: convert xfs_da_do_buf to use irec buffer interface Dave Chinner
2011-12-07 6:18 ` [PATCH 07/12] xfs: switch the buffer get/read API to use irec methods Dave Chinner
2011-12-07 6:18 ` [PATCH 08/12] xfs: support multiple irec maps in buffer code Dave Chinner
2011-12-07 6:18 ` [PATCH 09/12] xfs: support compund buffers in buf_item logging Dave Chinner
2011-12-07 6:18 ` [PATCH 10/12] xfs: use multiple irec xfs buf support in dabuf Dave Chinner
2011-12-07 6:18 ` [PATCH 11/12] xfs: remove struct xfs_dabuf and infrastructure Dave Chinner
2011-12-17 23:30 ` Christoph Hellwig
2011-12-07 6:18 ` [PATCH 12/12] xfs: remove duplication in transaction buffer operations Dave Chinner
2011-12-17 23:32 ` Christoph Hellwig
2011-12-07 6:35 ` [RFC, PATCH 0/12] xfs: compound buffers for directory blocks Christoph Hellwig
2011-12-07 9:23 ` Dave Chinner [this message]
2011-12-14 18:33 ` Christoph Hellwig
2011-12-18 23:01 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111207092320.GA14273@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox