The block I/O controller [LWN.net]

By Jonathan Corbet
November 7, 2009

I/O bandwidth allocation and control is a tricky problem; as was discussed here earlier this year, several groups have tried to solve this problem at different levels in the block I/O stack. At a minisummit in Tokyo, the developers behind various I/O controllers got together and decided on a multi-level approach to the problem. Since then, developer Vivek Goyal has remarked:

IO control is a huge problem and the moment we start addressing all the issues in one patchset, it bloats to unmanageable proportions and then nothing gets inside the kernel. So at io mini summit we agreed that lets take small steps and once a piece of code is inside the kernel and stabilized, take the next step. So this is the first step.

This first small step is a 20-part patch series implementing a proportional-weight I/O controller within the CFQ I/O scheduler. A new control group (cgroup) class (called "blkio") is created, with each group given an I/O weight between 100 and 1000. The available I/O bandwidth is then handed out to groups as determined by their configured weight.

Working within CFQ gives the I/O controller fine-grained control over how much bandwidth each group gets. On the other hand, CFQ is poorly positioned to identify block I/O traffic which is not directly generated by user space (writeback, for example) or to throttle activity at the virtual memory level. Achieving that will require the integration of a controller which hooks into the system at a much higher level. The plan is to write such a controller and have it work transparently within the same blkio cgroup. But a couple more small steps will probably be required before that is ready to go in.

Index entries for this article
Kernel	Block layer/I/O scheduling
Kernel	I/O scheduler