All of lore.kernel.org
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Fengguang Wu <fengguang.wu@intel.com>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
	Vivek Goyal <vgoyal@redhat.com>,
	Suresh Jayaraman <sjayaraman@suse.com>,
	Andrea Righi <andrea@betterlinux.com>,
	Jeff Moyer <jmoyer@redhat.com>,
	linux-fsdevel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/6] buffered write IO controller in balance_dirty_pages()
Date: Thu, 29 Mar 2012 09:34:04 +0900	[thread overview]
Message-ID: <4F73ADFC.7040404@jp.fujitsu.com> (raw)
In-Reply-To: <20120328121308.568545879@intel.com>

(2012/03/28 21:13), Fengguang Wu wrote:

> Here is one possible solution to "buffered write IO controller", based on Linux
> v3.3
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/linux.git  buffered-write-io-controller
> 
> Features:
> - support blkio.weight
> - support blkio.throttle.buffered_write_bps
> 
> Possibilities:
> - it's trivial to support per-bdi .weight or .buffered_write_bps
> 
> Pros:
> 1) simple
> 2) virtually no space/time overheads
> 3) independent of the block layer and IO schedulers, hence
> 3.1) supports all filesystems/storages, eg. NFS/pNFS, CIFS, sshfs, ...
> 3.2) supports all IO schedulers. One may use noop for SSDs, inside virtual machines, over iSCSI, etc.
> 
> Cons:
> 1) don't try to smooth bursty IO submission in the flusher thread (*)
> 2) don't support IOPS based throttling
> 3) introduces semantic differences to blkio.weight, which will be
>    - working by "bandwidth" for buffered writes
>    - working by "device time" for direct IO
> 
> (*) Maybe not a big concern, since the bursties are limited to 500ms: if one dd
> is throttled to 50% disk bandwidth, the flusher thread will be waking up on
> every 1 second, keep the disk busy for 500ms and then go idle for 500ms; if
> throttled to 10% disk bandwidth, the flusher thread will wake up on every 5s,
> keep busy for 500ms and stay idle for 4.5s.
> 
> The test results included in the last patch look pretty good in despite of the
> simple implementation.
> 

yes, seems very good.

>  [PATCH 1/6] blk-cgroup: move blk-cgroup.h in include/linux/blk-cgroup.h
>  [PATCH 2/6] blk-cgroup: account dirtied pages
>  [PATCH 3/6] blk-cgroup: buffered write IO controller - bandwidth weight
>  [PATCH 4/6] blk-cgroup: buffered write IO controller - bandwidth limit
>  [PATCH 5/6] blk-cgroup: buffered write IO controller - bandwidth limit interface
>  [PATCH 6/6] blk-cgroup: buffered write IO controller - debug trace
> 
> The changeset is dominated by the blk-cgroup.h move.
> The core changes (to page-writeback.c) are merely 77 lines.
> 
>  block/blk-cgroup.c               |   27 +
>  block/blk-cgroup.h               |  364 --------------------------
>  block/blk-throttle.c             |    2 
>  block/cfq.h                      |    2 
>  include/linux/blk-cgroup.h       |  396 +++++++++++++++++++++++++++++
>  include/trace/events/writeback.h |   34 ++
>  mm/page-writeback.c              |   77 +++++
>  7 files changed, 530 insertions(+), 372 deletions(-)
> 


Thank you very much. I like this simple implementation.
I have 3 questions..

- Do you have any plan to enhance this to support hierarchical accounting ?
- Can we get wait-time-for-dirty-pages summary per blkio cgroup ?
- Can we get status (dirty/sec) per blkio cgroup ?

Thanks,
-Kame

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

WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Fengguang Wu <fengguang.wu@intel.com>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
	Vivek Goyal <vgoyal@redhat.com>,
	Suresh Jayaraman <sjayaraman@suse.com>,
	Andrea Righi <andrea@betterlinux.com>,
	Jeff Moyer <jmoyer@redhat.com>,
	linux-fsdevel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/6] buffered write IO controller in balance_dirty_pages()
Date: Thu, 29 Mar 2012 09:34:04 +0900	[thread overview]
Message-ID: <4F73ADFC.7040404@jp.fujitsu.com> (raw)
In-Reply-To: <20120328121308.568545879@intel.com>

(2012/03/28 21:13), Fengguang Wu wrote:

> Here is one possible solution to "buffered write IO controller", based on Linux
> v3.3
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/linux.git  buffered-write-io-controller
> 
> Features:
> - support blkio.weight
> - support blkio.throttle.buffered_write_bps
> 
> Possibilities:
> - it's trivial to support per-bdi .weight or .buffered_write_bps
> 
> Pros:
> 1) simple
> 2) virtually no space/time overheads
> 3) independent of the block layer and IO schedulers, hence
> 3.1) supports all filesystems/storages, eg. NFS/pNFS, CIFS, sshfs, ...
> 3.2) supports all IO schedulers. One may use noop for SSDs, inside virtual machines, over iSCSI, etc.
> 
> Cons:
> 1) don't try to smooth bursty IO submission in the flusher thread (*)
> 2) don't support IOPS based throttling
> 3) introduces semantic differences to blkio.weight, which will be
>    - working by "bandwidth" for buffered writes
>    - working by "device time" for direct IO
> 
> (*) Maybe not a big concern, since the bursties are limited to 500ms: if one dd
> is throttled to 50% disk bandwidth, the flusher thread will be waking up on
> every 1 second, keep the disk busy for 500ms and then go idle for 500ms; if
> throttled to 10% disk bandwidth, the flusher thread will wake up on every 5s,
> keep busy for 500ms and stay idle for 4.5s.
> 
> The test results included in the last patch look pretty good in despite of the
> simple implementation.
> 

yes, seems very good.

>  [PATCH 1/6] blk-cgroup: move blk-cgroup.h in include/linux/blk-cgroup.h
>  [PATCH 2/6] blk-cgroup: account dirtied pages
>  [PATCH 3/6] blk-cgroup: buffered write IO controller - bandwidth weight
>  [PATCH 4/6] blk-cgroup: buffered write IO controller - bandwidth limit
>  [PATCH 5/6] blk-cgroup: buffered write IO controller - bandwidth limit interface
>  [PATCH 6/6] blk-cgroup: buffered write IO controller - debug trace
> 
> The changeset is dominated by the blk-cgroup.h move.
> The core changes (to page-writeback.c) are merely 77 lines.
> 
>  block/blk-cgroup.c               |   27 +
>  block/blk-cgroup.h               |  364 --------------------------
>  block/blk-throttle.c             |    2 
>  block/cfq.h                      |    2 
>  include/linux/blk-cgroup.h       |  396 +++++++++++++++++++++++++++++
>  include/trace/events/writeback.h |   34 ++
>  mm/page-writeback.c              |   77 +++++
>  7 files changed, 530 insertions(+), 372 deletions(-)
> 


Thank you very much. I like this simple implementation.
I have 3 questions..

- Do you have any plan to enhance this to support hierarchical accounting ?
- Can we get wait-time-for-dirty-pages summary per blkio cgroup ?
- Can we get status (dirty/sec) per blkio cgroup ?

Thanks,
-Kame


  parent reply	other threads:[~2012-03-29  0:34 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-28 12:13 [PATCH 0/6] buffered write IO controller in balance_dirty_pages() Fengguang Wu
2012-03-28 12:13 ` Fengguang Wu
2012-03-28 12:13 ` Fengguang Wu
2012-03-28 12:13 ` [PATCH 1/6] blk-cgroup: move blk-cgroup.h in include/linux/blk-cgroup.h Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13 ` [PATCH 2/6] blk-cgroup: account dirtied pages Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13 ` [PATCH 3/6] blk-cgroup: buffered write IO controller - bandwidth weight Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13 ` [PATCH 4/6] blk-cgroup: buffered write IO controller - bandwidth limit Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13 ` [PATCH 5/6] blk-cgroup: buffered write IO controller - bandwidth limit interface Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13 ` [PATCH 6/6] blk-cgroup: buffered write IO controller - debug trace Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 12:13   ` Fengguang Wu
2012-03-28 21:10 ` [PATCH 0/6] buffered write IO controller in balance_dirty_pages() Vivek Goyal
2012-03-28 21:10   ` Vivek Goyal
2012-03-28 22:35   ` Fengguang Wu
2012-03-28 22:35     ` Fengguang Wu
2012-03-29  2:48   ` Suresh Jayaraman
2012-03-29  2:48     ` Suresh Jayaraman
2012-03-29  0:34 ` KAMEZAWA Hiroyuki [this message]
2012-03-29  0:34   ` KAMEZAWA Hiroyuki
2012-03-29  1:22   ` Fengguang Wu
2012-03-29  1:22     ` Fengguang Wu
2012-04-01  4:16 ` Suresh Jayaraman
2012-04-01  4:16   ` Suresh Jayaraman
2012-04-01  8:30   ` Fengguang Wu
2012-04-01  8:30     ` Fengguang Wu
2012-04-01 20:56 ` Vivek Goyal
2012-04-01 20:56   ` Vivek Goyal
2012-04-03  8:00   ` Fengguang Wu
2012-04-03 14:53     ` Vivek Goyal
2012-04-03 14:53       ` Vivek Goyal
2012-04-03 23:32       ` Fengguang Wu
2012-04-03 23:32         ` Fengguang Wu

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=4F73ADFC.7040404@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=andrea@betterlinux.com \
    --cc=fengguang.wu@intel.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sjayaraman@suse.com \
    --cc=vgoyal@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.