lkml.org 
[lkml]   [2008]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH -mm 0/5] cgroup: block device i/o controller (v9)
    Hirokazu Takahashi wrote:
    > Hi,
    >
    >>> Hi,
    >>>
    >>>> TODO:
    >>>>
    >>>> * Try to push down the throttling and implement it directly in the I/O
    >>>> schedulers, using bio-cgroup (http://people.valinux.co.jp/~ryov/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
    >
    > This behavior depends on the version of memory-cgroup.
    > In the previous version, pages in the swap cache were owned by one of
    > the cgroups.
    >
    > Kamezawa-san, one of the implementer, told me he got this feature off
    > temporarily and he was going to turn it on again. I think this
    > workaround is chosen because the current implementation of memory
    > cgroup has a weak point under memory pressure.
    >
    >> 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?
    >
    > Bio-cgroup can't support pages in the swap cache temporarily with the
    > current linux kernel either since it shares the same infrastructure
    > with memory-cgroup.
    >
    > Now, they have just started to rewrite the infrastructure to track pages
    > with page_cgroup, which is going to give us good performance ever.
    > After that I'm going to enhance bio-cgroup more, such as dirty page
    > tracking. To tell the truth, I already have dirty pages tracking patch
    > for the current linux in my hand, which isn't posted yet. I'm going to
    > port it on the new infrastructure.
    >
    > If memory cgroup team change their mind, I will implement swap-pages
    > tracking in bio-cgroup.

    Very good! in any case it seems I'll get the tracking of swap-pages from
    someone else.. so I don't have to change/implement anything in my
    io-throttle patchset. :)

    I'll start to use bio-cgroup in io-throttle ASAP and do some tests. I'll
    keep you informed.

    Thanks,
    -Andrea


    \
     
     \ /
      Last update: 2008-09-18 16:41    [W:4.549 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site