From: Peter Zijlstra <peterz@infradead.org>
To: balbir@linux.vnet.ibm.com
Cc: Nikanth Karthikesan <knikanth@suse.de>,
Wu Fengguang <fengguang.wu@intel.com>,
Bill Davidsen <davidsen@tmr.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Jens Axboe <axboe@kernel.dk>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>
Subject: Re: [RFC][PATCH] Per file dirty limit throttling
Date: Wed, 18 Aug 2010 16:25:18 +0200 [thread overview]
Message-ID: <1282141518.1926.4048.camel@laptop> (raw)
In-Reply-To: <20100818140856.GE28417@balbir.in.ibm.com>
On Wed, 2010-08-18 at 19:38 +0530, Balbir Singh wrote:
> There is an ongoing effort to look at per-cgroup dirty limits and I
> honestly think it would be nice to do it at that level first. We need
> it there as a part of the overall I/O controller. As a specialized
> need it could handle your case as well.
Well, it would be good to isolate that to the cgroup code. Also from
what I understood, the plan was to simply mark dirty inodes with a
cgroup and use that from writeout_inodes() to write out inodes
specifically used by that cgroup.
That is, on top of what Andrea Righi already proposed, which would
provide the actual per cgroup dirty limit (although the per-bdi
proportions applied to a cgroup limit aren't strictly correct, but that
seems to be something you'll have to live with, a per-bdi-per-cgroup
proportion would simply be accounting insanity).
That is a totally different thing than what was proposed.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: balbir@linux.vnet.ibm.com
Cc: Nikanth Karthikesan <knikanth@suse.de>,
Wu Fengguang <fengguang.wu@intel.com>,
Bill Davidsen <davidsen@tmr.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Jens Axboe <axboe@kernel.dk>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>
Subject: Re: [RFC][PATCH] Per file dirty limit throttling
Date: Wed, 18 Aug 2010 16:25:18 +0200 [thread overview]
Message-ID: <1282141518.1926.4048.camel@laptop> (raw)
In-Reply-To: <20100818140856.GE28417@balbir.in.ibm.com>
On Wed, 2010-08-18 at 19:38 +0530, Balbir Singh wrote:
> There is an ongoing effort to look at per-cgroup dirty limits and I
> honestly think it would be nice to do it at that level first. We need
> it there as a part of the overall I/O controller. As a specialized
> need it could handle your case as well.
Well, it would be good to isolate that to the cgroup code. Also from
what I understood, the plan was to simply mark dirty inodes with a
cgroup and use that from writeout_inodes() to write out inodes
specifically used by that cgroup.
That is, on top of what Andrea Righi already proposed, which would
provide the actual per cgroup dirty limit (although the per-bdi
proportions applied to a cgroup limit aren't strictly correct, but that
seems to be something you'll have to live with, a per-bdi-per-cgroup
proportion would simply be accounting insanity).
That is a totally different thing than what was proposed.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-08-18 14:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-16 4:19 [RFC][PATCH] Per file dirty limit throttling Nikanth Karthikesan
2010-08-16 4:19 ` Nikanth Karthikesan
2010-08-16 11:05 ` Peter Zijlstra
2010-08-16 11:05 ` Peter Zijlstra
2010-08-17 5:09 ` Nikanth Karthikesan
2010-08-17 5:09 ` Nikanth Karthikesan
2010-08-17 8:24 ` Peter Zijlstra
2010-08-17 8:24 ` Peter Zijlstra
2010-08-18 9:22 ` Nikanth Karthikesan
2010-08-18 9:22 ` Nikanth Karthikesan
2010-08-18 9:58 ` Peter Zijlstra
2010-08-18 9:58 ` Peter Zijlstra
2010-08-18 14:08 ` Balbir Singh
2010-08-18 14:08 ` Balbir Singh
2010-08-18 14:25 ` Peter Zijlstra [this message]
2010-08-18 14:25 ` Peter Zijlstra
2010-08-18 14:48 ` Balbir Singh
2010-08-18 14:48 ` Balbir Singh
2010-08-23 12:19 ` Nikanth Karthikesan
2010-08-23 12:19 ` Nikanth Karthikesan
2010-08-16 16:53 ` Bill Davidsen
2010-08-16 16:53 ` Bill Davidsen
2010-08-17 2:53 ` Wu Fengguang
2010-08-17 2:53 ` Wu Fengguang
2010-08-17 2:41 ` Wu Fengguang
2010-08-17 2:41 ` Wu Fengguang
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=1282141518.1926.4048.camel@laptop \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=balbir@linux.vnet.ibm.com \
--cc=davidsen@tmr.com \
--cc=fengguang.wu@intel.com \
--cc=jack@suse.cz \
--cc=knikanth@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.