From: Joe Thornber <thornber@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: device-mapper development <dm-devel@redhat.com>,
"Alasdair G. Kergon" <agk@redhat.com>
Subject: Re: [PATCH 1/2] dm-kcopyd: introduce per-module throttle structure
Date: Thu, 9 Jun 2011 10:47:47 +0100 [thread overview]
Message-ID: <20110609094746.GA3152@ubuntu> (raw)
In-Reply-To: <Pine.LNX.4.64.1106071321300.8279@hs20-bc2-1.build.redhat.com>
Mikulas,
On Tue, Jun 07, 2011 at 01:50:16PM -0400, Mikulas Patocka wrote:
> I did some tests. I did some random and sequential I/O on the same disk
> while mirror was resynchronizing. The result is this:
>
> random read:
> mirror throttle / IOs per second
> 100% 94
> 75% 113
> 50% 127
> 25% 145
> idle 160
>
> sequential read:
> mirror throttle / throughput MB/s
> 100% 104
> 75% 118
> 50% 122
> 25% 127
> idle 134
This is nice to see, thanks for providing it. I'm still uneasy about
this throttling being time based though.
What we're trying to do is avoid kcopyd issuing so much io that it
interferes with userland io.
Now you've already posted some nice patches that remove the fixed
sized buffers in kcopyd clients, instead grabbing extra memory if it's
available, otherwise making do with a tiny preallocated buffer to
ensure progress. So as I see it, the amount of io that kcopyd submits
is dependent on the amount of memory available.
i) If there is lots of memory available can your throttling patch
still manage to issue too much io in the time that kcopyd is active?
ii) If there is little memory available few ios will be issued. But
your throttling will still occur, slowing things down even more.
I think it makes much more sense to throttle based on amount of io
issued by kcopyd. Either tracking throughput, or even just putting a
limit on the amount of io that can be in flight at any one time.
- Joe
next prev parent reply other threads:[~2011-06-09 9:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-31 22:03 [PATCH 1/2] dm-kcopyd: introduce per-module throttle structure Mikulas Patocka
2011-06-01 6:18 ` Ankit Jain
2011-06-01 7:13 ` Ankit Jain
2011-06-02 19:16 ` Mikulas Patocka
2011-06-01 9:51 ` Joe Thornber
2011-06-02 19:55 ` Mikulas Patocka
2011-06-03 11:01 ` Joe Thornber
2011-06-03 15:54 ` Mike Snitzer
2011-06-07 17:50 ` Mikulas Patocka
2011-06-09 9:47 ` Joe Thornber [this message]
2011-06-09 16:08 ` Mikulas Patocka
2011-06-09 16:27 ` Alasdair G Kergon
2011-06-10 8:44 ` Joe Thornber
2011-06-10 9:28 ` Lars Ellenberg
2011-06-10 10:14 ` Joe Thornber
2011-06-10 13:41 ` Mikulas Patocka
2011-06-10 13:48 ` Joe Thornber
2011-06-10 16:13 ` Lars Ellenberg
2011-06-10 13:51 ` Mike Snitzer
2011-06-11 20:27 ` Mikulas Patocka
2011-06-13 9:17 ` Joe Thornber
2011-06-13 21:06 ` Mikulas Patocka
2011-06-14 8:34 ` Joe Thornber
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=20110609094746.GA3152@ubuntu \
--to=thornber@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=mpatocka@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.