Re: [PATCH 1/3] i/o bandwidth controller documentation

[Andrea Righi <righi.andrea@gmail.com>]

Carl Henrik Lunde wrote:
> On Sat, Jun 7, 2008 at 00:27, Andrea Righi <righi.andrea@gmail.com> wrote:
> [...]
>> +3. Advantages of providing this feature
>> +
>> +* Allow QoS for block device I/O among different cgroups
> 
> I'm not sure if this can be called QoS, as it does not guarantee
> anything but throttling?

That's correct. There's nothing to guarantee minimum bandwidth levels
right now, the "QoS" is implemented only slowing down i/o "traffic" that
exceeds the limits (probably "i/o traffic shaping" is a better wording).

Minimum thresholds are supposed to be guaranteed if the user configures
a proper i/o bandwidth partitioning of the block devices shared among
the different cgroups (that could mean: the sum of all the single limits
for a device doesn't exceed the total i/o bandwidth of that device... at
least theoretically).

I'll try to clarify better this concept in the documentation that I'll
include in the next patchset version.

I'd also like to explore the io-throttle controller on-top-of other i/o
band controlling solutions (see for example:
http://lkml.org/lkml/2008/4/3/45), in order to exploit both the limiting
feature from io-throttle and use priority / fair queueing alghorithms to
guarantee minimum performance levels.

>> +* The bandwidth limitations are guaranteed both for synchronous and
>> +  asynchronous operations, even the I/O passing through the page cache or
>> +  buffers and not only direct I/O (see below for details)
> 
> The throttling does not seem to cover the I/O path for XFS?
> I was unable to throttle processes reading from an XFS file system.

mmmh... works for me. Are you sure you've limited the correct block
device?

> Also I think the name of the function cgroup_io_account is a bit too innocent?
> It sounds like a inline function "{ io += bytes; }", not like
> something which may sleep.

Agree. What about cgroup_acct_and_throttle_io()? suggestions?

Thanks,
-Andrea