On Fri, Apr 20, 2012 at 08:45:18PM +0800, Fengguang Wu wrote: [..] > If still keep the global async queue, it can run small 40ms slices > without defeating the flusher's 500ms granularity. After each slice > it can freely switch to other cgroups with sync IOs, so is free from > latency issues. After return, it will continue to serve the same > inode. It will basically be working on behalf of one cgroup for 500ms > data, working for another cgroup for 500ms data and so on. That > behavior does not impact fairness, because it's still using small > slices and its weight is computed system wide thus exhibits some kind > of smooth/amortize effects over long period of time. It can naturally > serve the same inode after return. Ok, So tejun did say that we will have a switch where we will allow retaining the old behavior of keeping all async writes in root group and not in individual group. So throughput sensitive users can make use of that and there is no need to push proportional IO logic to writeback layer for buffered writes? I am personally is not too excited about the case of putting async IO in separate groups due to the reason that async IO of one group will start impacting latencies of sync IO of another group and in practice it might not be desirable. But there are others who have use cases for separate async IO queue. So as long as switch is there to change the behavior, I am not too worried. 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
