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



Carl Henrik Lunde wrote:
On Sat, Jun 7, 2008 at 00:27, Andrea Righi <righi.andrea@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO
    ... I/O control people should prove it. ... is pretty easy and it shouldn't be hard to throttle the cgroup. ... As other project, I/O controller ... apparently without even thinking about the write throttling problems, ...
    (Linux-Kernel)
  • [PATCH -mm 1/3] i/o controller documentation
    ... Documentation of the block device I/O controller: ... +Bandwidth limiting rules offer better control over QoS with respect to priority ... +all the single limits defined for a block device doesn't exceed the total I/O ... +- STRATEGY is the throttling strategy used to throttle the applications' I/O ...
    (Linux-Kernel)
  • Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO
    ... I/O control people should prove it. ... The IO controller patches are undergoing review and ... Yeah, but if the design hasn't been fully validated, maybe the ... apparently without even thinking about the write throttling problems, ...
    (Linux-Kernel)
  • [RFC][PATCH -mm 0/5] cgroup: block device i/o controller (v9)
    ... The objective of the i/o controller is to improve i/o performance ... cgroup it belongs to) is forced to flush the same amount of pages back to the ... block device (in this way write operations are forced to occur in the same IO ... block device and task throttling statistics (throttle ...
    (Linux-Kernel)
  • Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO
    ... I/O control people should prove it. ... Yeah, but if the design hasn't been fully validated, maybe the ... review of these patches. ... apparently without even thinking about the write throttling problems, ...
    (Linux-Kernel)