[lkml]   [2011]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 00/12] IO-less dirty throttling v7
On Sat, Apr 16, 2011 at 09:25:46PM +0800, Wu Fengguang wrote:
> Andrew,
> This revision undergoes a number of simplifications, cleanups and fixes.
> Independent patches are separated out. The core patches (07, 08) now have
> easier to understand changelog. Detailed rationals can be found in patch 08.
> In response to the complexity complaints, an introduction document is
> written explaining the rationals, algorithm and visual case studies:

Hi Fenguang,

I went quickly browsed through above document and am trying to understand
the meaning of following lines and see how does it fit into the framework
of existing IO conroller.

- task IO controller endogenous
- cgroup IO controller well integrated
- proportional IO controller endogenous

You had sent me a link where you had prepared a patch to control the
async IO completely. So because this code is all about measuring the
bdi writeback rate and then coming up task ratelimit accoridingly, it
will never know about other IO going on in the cgroup. READS and direct

So IIUC, to make use of above logic for cgroup throttling, one shall have
to come up with explicity notion of async bandwidth per cgroup which does
not control other writes. Currently we have following when it comes to


The intention is to be able to control the WRITE bandwidth of cgroup and
it could be any kind of WRITE (be it buffered WRITE or direct WRITES).
Currently we control only direct WRITES and question of how to also
control buffered writes is still on the table.

Because your patch does not know about other WRITES happening in the
system, one needs to create a way so that buffered WRITES and direct
WRITES can be accounted together against a group and throttled

What does "proportional IO controller endogenous" mean? Currently we do
all proportional IO division in CFQ. So are you proposing that for
buffered WRITES we come up with a different policy altogether in writeback
layer or somehow it is integrating with CFQ mechanism?


 \ /
  Last update: 2011-04-26 19:23    [W:0.131 / U:1.860 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site