From: majianpeng <majianpeng@gmail.com>
To: shli <shli@kernel.org>
Cc: "Neil Brown" <neilb@suse.de>, viro <viro@zeniv.linux.org.uk>,
linux-raid <linux-raid@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Re: [PATCH 0/2] Improve odirect-write performance for block-device.
Date: Mon, 16 Jul 2012 13:43:13 +0800 [thread overview]
Message-ID: <201207161343099841872@gmail.com> (raw)
In-Reply-To: CANejiEW6znDtKZ+d5BzHb9TSM4ywC2CKyWhM95rJZJRgMgUZKw@mail.gmail.com
On 2012-07-16 11:29 Shaohua Li <shli@kernel.org> Wrote:
>2012/7/15 majianpeng <majianpeng@gmail.com>:
>> Create a raid5 using four disk and the chunksize is 512K.
>> Test command is: dd if=/dev/zero of=/dev/md0 bs=1536K count=90000 oflag=direct
>>
>> In RHEL6(kernel 2.6.32):speed about 240MB/s
>> In 3.5.0-rc5:speed about 77MB/S
>> Add two patch in 3.5.0-rc5, speed about 200MB/S.
>>
>> So the performance of odirect-wrirte for block-deivce was obvious reduced.
>> PATCH 1/2: Add blk_plug function for odirect-write block-device
>> PATCH 2/2: Remove REQ_SYNC for odirect-write in raid456.
>>
>> PATCH 2/2 maybe not correct because it alse for odirect-write for regular file.
>> Jianpeng Ma (2):
>> fs/block-dev.c:fix performance regression in O_DIRECT writes to
>> md block devices.
>
>In raid5, all requests are submitted by raid5d thread, which already has
>plug. Why doesn't it work?
No. the purpose of two patch is to reduce the read operation when write which was not full-write.
I tested in RHEL6.The read operation is zero.But in 3.5.0-rc5, the read operaiton may equal to write-operation.
And i used the bs was 1536k(3*512k(chunk-size)).
>
>> raid5: For write performance, remove REQ_SYNC when write was odirect.
>
>REQ_SYNC only impacts CFQ, this sounds not reasonable. So the disks
>are using CFQ ioscheduler. Can you check if you can see the same issue
>with deadline?
I tested and the result is the same like cfq.
But in RHEL6, the ioscheduler is also cfq.
>
>Let me guess, without REQ_SYNC, read will get higher priority against write
>in CFQ, so in this case, write gets delayed, and maybe get better write
>request merge. And now with REQ_SYNC, read and write has the same
>priority, there is less request merge.
>
>Thanks,
>Shaohua
For harddisk,the read for not full-write will remarkly reduce the performance.
So the first it to make write full-write as posible.
next prev parent reply other threads:[~2012-07-16 5:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-16 1:29 [PATCH 0/2] Improve odirect-write performance for block-device majianpeng
2012-07-16 3:29 ` Shaohua Li
2012-07-16 5:43 ` majianpeng [this message]
2012-07-16 13:21 ` Shaohua Li
2012-07-17 1:13 ` majianpeng
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=201207161343099841872@gmail.com \
--to=majianpeng@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=shli@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).