On Mon, Feb 28, 2011 at 11:15:02AM +0100, Andrea Righi wrote: [..] > TODO > ~~~~ > - Consider to add the following new files in the blkio controller to allow the > user to explicitly limit async writes as well as sync writes: > > blkio.throttle.async.write_bps_limit > blkio.throttle.async.write_iops_limit I am kind of split on this. - One way of thinking is that blkio.throttle.read/write_limits represent the limits on requeuest queue of the IO which is actually passing through queue now. So we should not mix the two and keep async limits separately. This will also tell the customer explicitly that async throttling does not mean the same thing as throttling happens before entering the page cache and there can be/will be IO spikes later at the request queue. Also creating the separate files leaves the door open for future extension of implementing async control when async IO is actually submitted to request queue. (Though I think that will be hard as making sure all the filesystems, writeback logic, device mapper drivers are aware of throttling and will take steps to ensure faster groups are not stuck behind slower groups). So keeping async accounting separate will help differentiating that async control is not same as sync control. There are fundamental differences. - On the other hand, it makes life a bit simple for user as they don't have to specify the async limits separately and there is one aggregate limit for sync and async (assuming we fix the throttling state issues so that throttling logic can handle both bio and task throttling out of single limit). Any thoughts? Thanks Vivek -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>