[lkml]   [2012]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] writeback and cgroup
    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.


     \ /
      Last update: 2012-04-20 21:33    [W:0.021 / U:10.752 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site