From: Ryo Tsuruta <ryov@valinux.co.jp>
To: baramsori72@gmail.com
Cc: linux-kernel@vger.kernel.org, dm-devel@redhat.com,
containers@lists.linux-foundation.org,
virtualization@lists.linux-foundation.org,
xen-devel@lists.xensource.com, agk@sourceware.org,
fernando@oss.ntt.co.jp, xemul@openvz.org,
balbir@linux.vnet.ibm.com
Subject: Re: [PATCH 0/2] dm-ioband: I/O bandwidth controller v1.7.0: Introduction
Date: Thu, 09 Oct 2008 21:14:14 +0900 (JST) [thread overview]
Message-ID: <20081009.211414.193713198.ryov@valinux.co.jp> (raw)
In-Reply-To: <2891419e0810082315v28f2f4cbu5f95230db3be0bc1@mail.gmail.com>
Hi Dong-Jae,
> So, I tested dm-ioband and bio-cgroup patches with another IO testing
> tool, xdd ver6.5(http://www.ioperformance.com/), after your reply.
> Xdd supports O_DIRECT mode and time limit options.
> I think, personally, it is proper tool for testing of IO controllers
> in Linux Container ML.
Xdd is really useful for me. Thanks for letting me know.
> And I found some strange points in test results. In fact, it will be
> not strange for other persons^^
>
> 1. dm-ioband can control IO bandwidth well in O_DIRECT mode(read and
> write), I think the result is very reasonable. but it can't control it
> in Buffered mode when I checked just only output of xdd. I think
> bio-cgroup patches is for solving the problems, is it right? If so,
> how can I check or confirm the role of bio-cgroup patches?
>
> 2. As showed in test results, the IO performance in Buffered IO mode
> is very low compared with it in O_DIRECT mode. In my opinion, the
> reverse case is more natural in real life.
> Can you give me a answer about it?
Your results show all xdd programs belong to the same cgroup,
could you explain me in detail about your test procedure?
To know how many I/Os are actually issued to a physical device in
buffered mode within a measurement period, you should check the
/sys/block/<dev>/stat file just before starting a test program and
just after the end of the test program. The contents of the stat file
is described in the following document:
kernel/Documentation/block/stat.txt
> 3. Compared with physical bandwidth(when it is checked with one
> process and without dm-ioband device), the sum of the bandwidth by
> dm-ioband has very considerable gap with the physical bandwidth. I
> wonder the reason. Is it overhead of dm-ioband or bio-cgroup patches?
> or Are there any another reasons?
The followings are the results on my PC with SATA disk, and there is
no big difference between with and without dm-ioband. Please try the
same thing if you have time.
without dm-ioband
=================
# xdd.linux -op write -queuedepth 16 -targets 1 /dev/sdb1 \
-reqsize 8 -numreqs 128000 -verbose -timelimit 30 -dio -randomize
T Q Bytes Ops Time Rate IOPS Latency
%CPU OP_Type ReqSize
0 16 140001280 17090 30.121 4.648 567.38 0.0018
0.01 write 8192
with dm-ioband
==============
* cgroup1 (weight 10)
# cat /cgroup/1/bio.id
1
# echo $$ > /cgroup/1/tasks
# xdd.linux -op write -queuedepth 16 -targets 1 /dev/mapper/ioband1
-reqsize 8 -numreqs 128000 -verbose -timelimit 30 -dio -randomize
T Q Bytes Ops Time Rate IOPS Latency
%CPU OP_Type ReqSize
0 16 14393344 1757 30.430 0.473 57.74 0.0173
0.00 write 8192
* cgroup2 (weight 20)
# cat /cgroup/2/bio.id
2
# echo $$ > /cgroup/2/tasks
# xdd.linux -op write -queuedepth 16 -targets 1 /dev/mapper/ioband1
-reqsize 8 -numreqs 128000 -verbose -timelimit 30 -dio -randomize
T Q Bytes Ops Time Rate IOPS Latency
%CPU OP_Type ReqSize
0 16 44113920 5385 30.380 1.452 177.25 0.0056
0.00 write 8192
* cgroup3 (weight 60)
# cat /cgroup/3/bio.id
3
# echo $$ > /cgroup/3/tasks
# xdd.linux -op write -queuedepth 16 -targets 1 /dev/mapper/ioband1
-reqeize 8 -numreqs 128000 -verbose -timelimit 30 -dio -randomize
T Q Bytes Ops Time Rate IOPS Latency
%CPU OP_Type ReqSize
0 16 82485248 10069 30.256 2.726 332.79 0.0030
0.00 write 8192
Total
=====
Bytes Ops Rate IOPS
w/o dm-ioband 140001280 17090 4.648 567.38
w/ dm-ioband 140992512 17211 4.651 567.78
> > Could you give me the O_DIRECT patch?
> >
> Of course, if you want. But it is nothing
> Tiobench tool is very simple and light source code, so I just add the
> O_DIRECT option in tiotest.c of tiobench testing tool.
> Anyway, after I make a patch file, I send it to you
Thank you very much!
Ryo Tsuruta
prev parent reply other threads:[~2008-10-09 12:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-03 5:37 Ryo Tsuruta
2008-10-03 5:38 ` [PATCH 1/2] dm-ioband: I/O bandwidth controller v1.7.0: Source code and patch Ryo Tsuruta
2008-10-03 5:39 ` [PATCH 2/2] dm-ioband: I/O bandwidth controller v1.7.0: Document Ryo Tsuruta
2008-10-08 8:29 ` [PATCH 0/2] dm-ioband: I/O bandwidth controller v1.7.0: Introduction Dong-Jae Kang
2008-10-08 10:40 ` Ryo Tsuruta
2008-10-09 6:15 ` Dong-Jae Kang
2008-10-09 12:14 ` Ryo Tsuruta [this message]
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=20081009.211414.193713198.ryov@valinux.co.jp \
--to=ryov@valinux.co.jp \
--cc=agk@sourceware.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=baramsori72@gmail.com \
--cc=containers@lists.linux-foundation.org \
--cc=dm-devel@redhat.com \
--cc=fernando@oss.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=xemul@openvz.org \
--cc=xen-devel@lists.xensource.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
all inboxes | Powered by JetHome®