[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120412205148.GA24056@google.com>
Date: Thu, 12 Apr 2012 13:51:48 -0700
From: Tejun Heo <tj@...nel.org>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: Jan Kara <jack@...e.cz>, Fengguang Wu <fengguang.wu@...el.com>,
Jens Axboe <axboe@...nel.dk>, linux-mm@...ck.org,
sjayaraman@...e.com, andrea@...terlinux.com, jmoyer@...hat.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
kamezawa.hiroyu@...fujitsu.com, lizefan@...wei.com,
containers@...ts.linux-foundation.org, cgroups@...r.kernel.org,
ctalbott@...gle.com, rni@...gle.com, lsf@...ts.linux-foundation.org
Subject: Re: [RFC] writeback and cgroup
Hello, Vivek.
On Thu, Apr 12, 2012 at 04:37:19PM -0400, Vivek Goyal wrote:
> I mean how are we supposed to put cgroup throttling rules using cgroup
> interface for network filesystems and for btrfs global bdi. Using "dev_t"
> associated with bdi? I see that all the bdi's are showing up in
> /sys/class/bdi, but how do I know which one I am intereste in or which
> one belongs to filesystem I am interestd in putting throttling rule on.
>
> For block devices, we simply use "major:min limit" format to write to
> a cgroup file and this configuration will sit in one of the per queue
> per cgroup data structure.
>
> I am assuming that when you say throttling should happen at bdi, you
> are thinking of maintaining per cgroup per bdi data structures and user
> is somehow supposed to pass "bdi_maj:bdi_min limit" through cgroup files?
> If yes, how does one map a filesystem's bdi we want to put rules on?
I think you're worrying way too much. One of the biggest reasons we
have layers and abstractions is to avoid worrying about everything
from everywhere. Let block device implement per-device limits. Let
writeback work from the backpressure it gets from the relevant IO
channel, bdi-cgroup combination in this case.
For stacked or combined devices, let the combining layer deal with
piping the congestion information. If it's per-file split, the
combined bdi can simply forward information from the matching
underlying device. If the file is striped / duplicated somehow, the
*only* layer which knows what to do is and should be the layer
performing the striping and duplication. There's no need to worry
about it from blkcg and if you get the layering correct it isn't
difficult to slice such logic inbetween. In fact, most of it
(backpressure propagation) would just happen as part of the usual
buffering between layers.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists