On Mon, Mar 05, 2012 at 03:51:32PM -0800, Fengguang Wu wrote: > On Tue, Mar 06, 2012 at 12:19:30AM +0100, Andrea Righi wrote: > > On Mon, Mar 05, 2012 at 02:30:29PM -0800, Fengguang Wu wrote: > > > On Mon, Mar 05, 2012 at 04:11:15PM -0500, Vivek Goyal wrote: > > ... > > > > But looks like we don't much choice. As buffered writes can be controlled > > > > at two levels, we probably need two knobs. Also controlling writes while > > > > entring cache limits will be global and not per device (unlinke currnet > > > > per device limit in blkio controller). Having separate control for "dirty > > > > rate limit" leaves the scope for implementing write control at device > > > > level in the future (As some people prefer that). In possibly two > > > > solutions can co-exist in future. > > > > > > Good point. balance_dirty_pages() has no idea about the devices at > > > all. So the rate limit for buffered writes can hardly be unified with > > > the per-device rate limit for direct writes. > > > > > > > I think balance_dirty_pages() can have an idea about devices. We can get > > a reference to the right block device / request queue from the > > address_space: > > > > bdev = mapping->host->i_sb->s_bdev; > > q = bdev_get_queue(bdev); > > > > (NULL pointer dereferences apart). > > Problem is, there is no general 1:1 mapping between bdev and disks. > For the single disk multpile partitions (sda1, sda2...) case, the > above scheme is fine and makes the throttle happen at sda granularity. > > However for md/dm etc. there is no way (or need?) to reach the exact > disk that current blkcg is operating on. > > Thanks, > Fengguang Oh I see, the problem is with stacked block devices. Right, if we set a limit for sda and a stacked block device is defined over sda, we'd get only the bdev at the top of the stack at balance_dirty_pages() and the limits configured for the underlying block devices will be ignored. However, maybe for the 90% of the cases this is fine, I can't see a real world scenario where we may want to limit only part or indirectly a stacked block device... Thanks, -Andrea -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
