From: dongmao zhang <dmzhang@suse.com>
To: dm-devel@redhat.com
Cc: dongmao zhang <dmzhang@suse.com>
Subject: [PATCH 0/1] ideas to improve the write performance of cluster dm-raid1
Date: Tue, 10 Sep 2013 17:25:11 +0800 [thread overview]
Message-ID: <cover.1378804287.git.dmzhang@suse.com> (raw)
In-Reply-To: <yes>
Dear list,
Based on my test result, the cluster raid1 writes loss 80% performance. I found
that the most time is occupied by the function userspace_flush.
Usually userspace_flush needs three stages(mark, clear, flush)to communicate with cmirrord.
From the cmirrord's perspective, mark and flush functions run cluster_send first and then return to
the kernel. And we can ignore the clear request which is fast.
In other words, the requests of mark_region and flush in userspace_flush
at least require a cluster_send period to finish. this is the root cause
of bad performance.
The idea is to merge flush and mark request together in both cmirrord and dm-log-userspace.
A simple patch for cmirrord could be like this:
--- lvm2-2_02_98.orig/daemons/cmirrord/functions.c
+++ lvm2-2_02_98/daemons/cmirrord/functions.c
@@ -1720,7 +1720,8 @@ int do_request(struct clog_request *rq,
r = clog_flush(&rq->u_rq, server);
break;
case DM_ULOG_MARK_REGION:
- r = clog_mark_region(&rq->u_rq, rq->originator);
+ if (clog_mark_region(&rq->u_rq, rq->originator) == 0)
+ r = clog_flush(&rq->u_rq, server);
break;
case DM_ULOG_CLEAR_REGION:
r = clog_clear_region(&rq->u_rq, rq->originator);
We run clog_flush directly after clog_mark_region. So the userspace_flush do not
have to request flush again after requesting mark_region. Moreover, I think the flush
of clear region could be delayed. If we have both mark and clear region, only sending
a mark_region request is OK, because clog_flush will automatically run.(ignore the clean_region
time). It only takes one cluster_send period. If we have only mark region,
a mark_region request is also OK, it takes one cluster_send period. If we have only
clear_region, we could delay the flush of cleared_region for 3 seconds.
Overall, before the patch, mark_region require approximately two cluster_send
period(mark_region and flush), after the patch, mark_region only needs one
cluster_send period. Based on my test, the performance is as twice as before.
So above are my some ideas to improve the performence. I have not tested it
in some node failure situation. If I am wrong ,please correct me.
dongmao zhang (1):
improve the performance of dm-log-userspace
drivers/md/dm-log-userspace-base.c | 57 ++++++++++++++++++++++++++++++++---
1 files changed, 52 insertions(+), 5 deletions(-)
--
1.7.3.4
next parent reply other threads:[~2013-09-10 9:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <yes>
2013-09-10 9:25 ` dongmao zhang [this message]
2013-09-10 9:25 ` [PATCH 1/1] improve the performance of dm-log-userspace dongmao zhang
2013-10-28 10:07 ` [PATCH 0/1] patches to improve cluster raid1 performance [V3] dongmao zhang
2013-10-28 10:07 ` [PATCH 1/1] improve the performance of dm-log-userspace dongmao zhang
2013-10-30 1:35 ` Brassow Jonathan
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=cover.1378804287.git.dmzhang@suse.com \
--to=dmzhang@suse.com \
--cc=dm-devel@redhat.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;
as well as URLs for NNTP newsgroup(s).