From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Jan Kara <jack@suse.cz>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
chris.mason@oracle.com, david@fromorbit.com, hch@infradead.org,
akpm@linux-foundation.org
Subject: Re: [PATCH 0/11] Per-bdi writeback flusher threads #4
Date: Mon, 25 May 2009 16:54:44 +0800 [thread overview]
Message-ID: <1243241684.2560.121.camel@ymzhang> (raw)
In-Reply-To: <20090522081539.GM11363@kernel.dk>
On Fri, 2009-05-22 at 10:15 +0200, Jens Axboe wrote:
> > > > > > > > > > > > > This is the fourth version of this patchset. Chances since v3:
> Thanks, I'll get this reproduced and fixed. Can you post the results
> you got comparing writeback and vanilla meanwhile?
I didn't post the result because some test cases benefit from the patches
while others are hurt from the patches. Sometime one case benefit from the patches
on this machine, but is hurt on another machine.
As a matter of fact, I tested the patches on 4 machines. One machine which
triggered the bug has only 1 disk. The other 3 machines have 1 JBOD per machine.
1) machine lkp-st02 (stoakley): has a fiberchannel JBOD with 13 SCSI disks. Every
disk has 1 partition (ext3 filesystem). Memory is 8GB.
2) machine lkp-st01: has a SAS JBOD with 7 SAS disks. Every disk has 2
partitions. 8GB memory.
3) Machine lkp-ne02 (nehalem): has a SATA JBOD with 11 disks. Every disk has
2 partitions. 6GB memory.
The HBA cards connecting to JBOD have no raid capability,
or they have, but I don't turn raid on.
Mount ext3 with option '-o writeback'.
Below results focus on the 3 machines who have JBOD.
I use iozone/tiobench/fio/ffsb for this testing. With iozone/tiobench, I always
use one disk on all machines. But with fio/ffsb which has lots of subtest cases,
I use all disks of the JBOD connecting to the corresponding machine.
The comparation is between 2.6.30-rc6 and 2.6.30-rc6+V4_patches, or plus
3 new patches (starting with 0001~0003).
1) iozone: 500MB iozone testing has no result difference. But 1.2GB testing has
about 40% regression on rewrite with the 3 new patches (001~003). If no the 3 new
patches, the regression is more than 90%. write has the simular regression, but its
regression disappears with the new 3 patches.
2) tiobench: result variation is considered as fluctuation.
3) fio: consists of more than 30 sub test cases, including sync/aio/mmap,
plus the combination with block size (less4k/4k/64k, soetimes 128k) and random.
As for write testing, mostly, one thread per partition.
Mostly, fio_mmap_randwrite(randrw)_4k_preread has 5%~30% improvement. But with
the new 3 patches, the improvement becomes smaller, for example becomes 14% from 30%.
fio_mmap_randwrite has 5%~10% regression on lkp-st01 and lkp-ne02 (both machines'
JBOD has 2 partitions per disk), but has 2%~15% improvement on lkp-st02 (one partition
per disk).fio_mmap_randrw has the similar behavior.
fio_mmap_randwrite_4k_halfbusy (Use 4 disks and less workload than other fio cases)
has about 20%~30% improvement.
fio sync read has about 15%~30% regression on lkp-st01, but the regression disappears
with the 3 new patches. Other machines haven't the issue.
aio has no regression.
4) ffsb:
ffsb_create (blocksize 4k, 64k) has 10%~20% improvement on lkp-st01 and
lkp-ne02, but hasn't on lkp-st02.
The data of other ffsb test cases looks suspicious, so I need double-check it, or
tune parameters to rerun.
Yanmin
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-05-25 8:54 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-18 12:19 [PATCH 0/11] Per-bdi writeback flusher threads #4 Jens Axboe
2009-05-18 12:19 ` [PATCH 01/11] writeback: move dirty inodes from super_block to backing_dev_info Jens Axboe
2009-05-18 12:19 ` [PATCH 02/11] writeback: switch to per-bdi threads for flushing data Jens Axboe
2009-05-19 10:20 ` Richard Kennedy
2009-05-19 12:23 ` Jens Axboe
2009-05-19 13:45 ` Richard Kennedy
2009-05-19 17:56 ` Jens Axboe
2009-05-19 22:11 ` Peter Zijlstra
2009-05-20 11:18 ` Jan Kara
2009-05-20 11:32 ` Jens Axboe
2009-05-20 12:11 ` Jan Kara
2009-05-20 12:16 ` Jens Axboe
2009-05-20 12:24 ` Christoph Hellwig
2009-05-20 12:48 ` Jens Axboe
2009-05-20 12:37 ` Christoph Hellwig
2009-05-20 12:49 ` Jens Axboe
2009-05-20 14:02 ` Anton Altaparmakov
2009-05-18 12:19 ` [PATCH 03/11] writeback: get rid of pdflush completely Jens Axboe
2009-05-18 12:19 ` [PATCH 04/11] writeback: separate the flushing state/task from the bdi Jens Axboe
2009-05-20 11:34 ` Jan Kara
2009-05-20 11:39 ` Jens Axboe
2009-05-20 12:06 ` Jan Kara
2009-05-20 12:09 ` Jens Axboe
2009-05-18 12:19 ` [PATCH 05/11] writeback: support > 1 flusher thread per bdi Jens Axboe
2009-05-18 12:19 ` [PATCH 06/11] writeback: include default_backing_dev_info in writeback Jens Axboe
2009-05-18 12:19 ` [PATCH 07/11] writeback: allow sleepy exit of default writeback task Jens Axboe
2009-05-18 12:19 ` [PATCH 08/11] writeback: btrfs must register its backing_devices Jens Axboe
2009-05-18 12:19 ` [PATCH 09/11] writeback: add some debug inode list counters to bdi stats Jens Axboe
2009-05-18 12:19 ` [PATCH 10/11] writeback: add name to backing_dev_info Jens Axboe
2009-05-18 12:19 ` [PATCH 11/11] writeback: check for registered bdi in flusher add and inode dirty Jens Axboe
2009-05-19 6:11 ` [PATCH 0/11] Per-bdi writeback flusher threads #4 Zhang, Yanmin
2009-05-19 6:20 ` Jens Axboe
2009-05-19 6:43 ` Zhang, Yanmin
2009-05-20 7:51 ` Zhang, Yanmin
2009-05-20 8:09 ` Jens Axboe
2009-05-20 8:54 ` Jens Axboe
2009-05-20 9:19 ` Zhang, Yanmin
2009-05-20 9:25 ` Jens Axboe
2009-05-20 11:19 ` Jens Axboe
2009-05-21 6:33 ` Zhang, Yanmin
2009-05-21 9:10 ` Jan Kara
2009-05-22 1:28 ` Zhang, Yanmin
2009-05-22 8:15 ` Jens Axboe
2009-05-22 20:44 ` Jens Axboe
2009-05-23 19:15 ` Jens Axboe
2009-05-25 8:02 ` Zhang, Yanmin
2009-05-25 8:06 ` Jens Axboe
2009-05-25 8:43 ` Zhang, Yanmin
2009-05-25 8:48 ` Jens Axboe
2009-05-25 8:54 ` Zhang, Yanmin [this message]
2009-05-22 7:53 ` Jens Axboe
2009-05-22 7:53 ` Jens Axboe
2009-05-25 15:57 ` Richard Kennedy
2009-05-25 17:05 ` Jens Axboe
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=1243241684.2560.121.camel@ymzhang \
--to=yanmin_zhang@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jens.axboe@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).