[lkml]   [2008]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH -mm 0/5] cgroup: block device i/o controller (v9)
    On Wed, Sep 17, 2008 at 10:47:54AM +0200, Andrea Righi wrote:
    > Hirokazu Takahashi wrote:
    > > Hi,
    > >
    > >> TODO:
    > >>
    > >> * Try to push down the throttling and implement it directly in the I/O
    > >> schedulers, using bio-cgroup (
    > >> to keep track of the right cgroup context. This approach could lead to more
    > >> memory consumption and increases the number of dirty pages (hard/slow to
    > >> reclaim pages) in the system, since dirty-page ratio in memory is not
    > >> limited. This could even lead to potential OOM conditions, but these problems
    > >> can be resolved directly into the memory cgroup subsystem
    > >>
    > >> * Handle I/O generated by kswapd: at the moment there's no control on the I/O
    > >> generated by kswapd; try to use the page_cgroup functionality of the memory
    > >> cgroup controller to track this kind of I/O and charge the right cgroup when
    > >> pages are swapped in/out
    > >
    > > FYI, this also can be done with bio-cgroup, which determine the owner cgroup
    > > of a given anonymous page.
    > >
    > > Thanks,
    > > Hirokazu Takahashi
    > That would be great! FYI here is how I would like to proceed:
    > - today I'll post a new version of my cgroup-io-throttle patch rebased
    > to 2.6.27-rc5-mm1 (it's well tested and seems to be stable enough).
    > To keep the things light and simpler I've implemented custom
    > get_cgroup_from_page() / put_cgroup_from_page() in the memory
    > controller to retrieve the owner of a page, holding a reference to the
    > corresponding memcg, during async writes in submit_bio(); this is not
    > probably the best way to proceed, and a more generic framework like
    > bio-cgroup sounds better, but it seems to work quite well. The only
    > problem I've found is that during swap_writepage() the page is not
    > assigned to any page_cgroup (page_get_page_cgroup() returns NULL), and
    > so I'm not able to charge the cost of this I/O operation to the right
    > cgroup. Does bio-cgroup address or even resolve this issue?
    > - begin to implement a new branch of cgroup-io-throttle on top of
    > bio-cgroup
    > - also start to implement an additional request queue to provide first a
    > control at the cgroup level and a dispatcher to pass the request to
    > the elevator (as suggested by Vivek)

    Hi Andrea,

    So if we maintain and rb-tree per request queue and implement the cgroup
    rules there, then that will take care of io-throttling also. (One can
    control the release of bio/requests to elevator based on any kind of
    rules. proportional weight/max-bandwidth).

    If that's the case, I was wondering what do you mean by "begin to
    implement new branch of cgroup-io-throttle" on top of bio-cgroup".


     \ /
      Last update: 2008-09-18 16:07    [W:0.056 / U:164.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site