From: Vivek Goyal <vgoyal@redhat.com>
To: Andrea Righi <arighi@develer.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Greg Thelen <gthelen@google.com>,
Wu Fengguang <fengguang.wu@intel.com>,
Gui Jianfeng <guijianfeng@cn.fujitsu.com>,
Ryo Tsuruta <ryov@valinux.co.jp>,
Hirokazu Takahashi <taka@valinux.co.jp>,
Jens Axboe <axboe@kernel.dk>, Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
containers@lists.linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] blk-throttle: async write throttling
Date: Tue, 1 Mar 2011 11:27:53 -0500 [thread overview]
Message-ID: <20110301162753.GB2539@redhat.com> (raw)
In-Reply-To: <1298888105-3778-1-git-send-email-arighi@develer.com>
On Mon, Feb 28, 2011 at 11:15:02AM +0100, Andrea Righi wrote:
[..]
> TODO
> ~~~~
> - Consider to add the following new files in the blkio controller to allow the
> user to explicitly limit async writes as well as sync writes:
>
> blkio.throttle.async.write_bps_limit
> blkio.throttle.async.write_iops_limit
I am kind of split on this.
- One way of thinking is that blkio.throttle.read/write_limits represent
the limits on requeuest queue of the IO which is actually passing
through queue now. So we should not mix the two and keep async limits
separately. This will also tell the customer explicitly that async
throttling does not mean the same thing as throttling happens before
entering the page cache and there can be/will be IO spikes later
at the request queue.
Also creating the separate files leaves the door open for future
extension of implementing async control when async IO is actually
submitted to request queue. (Though I think that will be hard as
making sure all the filesystems, writeback logic, device mapper
drivers are aware of throttling and will take steps to ensure faster
groups are not stuck behind slower groups).
So keeping async accounting separate will help differentiating that
async control is not same as sync control. There are fundamental
differences.
- On the other hand, it makes life a bit simple for user as they don't
have to specify the async limits separately and there is one aggregate
limit for sync and async (assuming we fix the throttling state issues
so that throttling logic can handle both bio and task throttling out
of single limit).
Any thoughts?
Thanks
Vivek
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-03-01 16:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 10:15 [PATCH 0/3] blk-throttle: async write throttling Andrea Righi
2011-02-28 10:15 ` [PATCH 1/3] block: introduce REQ_DIRECT to track direct io bio Andrea Righi
2011-02-28 10:15 ` [PATCH 2/3] blkio-throttle: infrastructure to throttle async io Andrea Righi
2011-03-01 16:06 ` Vivek Goyal
2011-03-02 13:31 ` Andrea Righi
2011-02-28 10:15 ` [PATCH 3/3] blkio-throttle: async write io instrumentation Andrea Righi
2011-02-28 23:01 ` [PATCH 0/3] blk-throttle: async write throttling Vivek Goyal
2011-03-02 13:28 ` Andrea Righi
2011-03-02 21:47 ` Vivek Goyal
2011-03-06 15:52 ` Andrea Righi
2011-03-07 7:31 ` Gui Jianfeng
2011-03-07 11:34 ` Andrea Righi
2011-03-07 11:44 ` Gui Jianfeng
2011-03-07 11:59 ` Andrea Righi
2011-03-07 12:15 ` Gui Jianfeng
2011-03-07 15:22 ` Vivek Goyal
2011-03-02 22:00 ` Greg Thelen
2011-03-01 16:27 ` Vivek Goyal [this message]
2011-03-01 21:40 ` Vivek Goyal
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=20110301162753.GB2539@redhat.com \
--to=vgoyal@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arighi@develer.com \
--cc=axboe@kernel.dk \
--cc=balbir@linux.vnet.ibm.com \
--cc=containers@lists.linux-foundation.org \
--cc=corbet@lwn.net \
--cc=fengguang.wu@intel.com \
--cc=gthelen@google.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nishimura@mxp.nes.nec.co.jp \
--cc=ryov@valinux.co.jp \
--cc=taka@valinux.co.jp \
/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).