OpenVZ Forum - RDF feed
type: channel
items: Re: [PATCH 0/3] cgroup: block device i/o bandwidth controller

Re: [PATCH 0/3] cgroup: block device i/o bandwidth controller
type: item
description: Andrea Righi wrote: > I'm resending an updated version of the cgroup I/O bandwidth controller > that I wrote some months ago (http://lwn.net/Articles/265944), since > someone asked me recently. > > The goal of this patchset is to implement a block device I/O bandwidth > controller using cgroups. > > Detailed informations about design, its goal and usage are described in > the documentation. > > Review, comments and feedbacks are welcome. > Hi, Andrea, There are several parallel efforts for the IO controller? Could you describe/compare them with yours? Is any consensus building taking place? CC'ing containers mailing list. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2008-05-24T18:22:50-00:00

Re: [PATCH 0/3] cgroup: block device i/o bandwidth controller
type: item
description: Balbir Singh wrote: > Andrea Righi wrote: >> I'm resending an updated version of the cgroup I/O bandwidth controller >> that I wrote some months ago (http://lwn.net/Articles/265944), since >> someone asked me recently. >> >> The goal of this patchset is to implement a block device I/O bandwidth >> controller using cgroups. >> >> Detailed informations about design, its goal and usage are described in >> the documentation. >> >> Review, comments and feedbacks are welcome. >> > > Hi, Andrea, > > There are several parallel efforts for the IO controller? Could you > describe/compare them with yours? Is any consensus building taking place? > > CC'ing containers mailing list. > Hi Balbir, I've seen the Ryo Tsuruta's dm-band (http://lwn.net/Articles/266257), the CFQ cgroup solution proposed by Vasily Tarasov (http://lwn.net/Articles/274652) and a similar approach by Satoshi Uchida (http://lwn.net/Articles/275944). First one is implemented at the device mapper layer and AFAIK at the moment it allows only to define per-task, per-user and per-group rules (cgroup support is in the TODO list anyway). Second and third solutions are implemented at the i/o scheduler layer, CFQ in particular. They work as expected with direct i/o operations (or synchronous reads). The problem is: how to limit the i/o activity of an applicaton that already wrote all the data in memory? The i/o scheduler is not the right place to throttle application writes, because it's "too late". At the very least we can map back the i/o path to find which process originally dirtied memory and depending on this information delay the dispatching of the requests. However, this needs bigger buffers, more page cache usage, that can lead to potential OOM conditions in massively shared environments. So, my approach has the disadvantage or the advantage (depending on the context and the requirements) to explicitly choke applications' requests. Other solutions that operates in the subsystem used to dispatch i/o requests ar…
creator: Andrea Righi
date: 2008-05-24T22:28:06-00:00

Re: [PATCH 0/3] cgroup: block device i/o bandwidth controller
type: item
description: Andrea Righi wrote: > So, my approach has the disadvantage or the advantage (depending on the > context and the requirements) to explicitly choke applications' > requests. Other solutions that operates in the subsystem used to > dispatch i/o requests are probably better to maximize overall > performance, but do not offer the same control over a real QoS as > request limiting can do. > > Another difference is that all of them are priority/weighted based. The > io-throttle controller, instead, allows to define direct bandwidth > limiting rules. The difference here is that priority based approach > propagates bursts and does no smoothing. Bandwidth limiting approach > controls bursts by smoothing the i/o rate. This means better performance > predictability at the cost of poor throughput optimization. > > I'll run some benchmarks and post the results ASAP. It would be also > interesting to run the same benchmarks using the other i/o controllers > and compare the results in terms of fairness, performance > predictability, responsiveness, throughput, etc. I'll see what I can do. Here is the test report of the benchmarks. Comments, suggestions, disapprovals, etc. are welcome. Tests are mainly focused to demonstrate how the io-throttle controller can be used to improve the i/o performance predictability on shared block devices (usually any block device shared by many users and processes, that can be grouped togheter by cgroup). The goal of the tests is *not* to compare the overall performance of the different solutions. Tests have been performed using an ext3 fs + CFQ i/o scheduler on /dev/sda. Following some details of the testbed host: # hdparm -i /dev/sda /dev/sda: Model=SAMSUNG HS08XJC , FwRev=GR100-01, Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=34902, SectSize=0, ECCbytes=4 BuffType=DualPortCache, BuffSize=7986kB, MaxMultSect=16, MultSect=?8? CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488 IORDY=on/off, tPIO={m…
creator: Andrea Righi
date: 2008-06-02T11:17:31-00:00