linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).