On Tue, Mar 06, 2012 at 01:46:02AM +0100, Andrea Righi wrote: [..] > > > > 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... I agree that throttling will make most sense on the top most device in the stack. If we try to do anything on the intermediate device, it might not make much sense and we will most likely lose context also. Thanks Vivek -- 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
