lkml.org 
[lkml]   [2011]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v6 0/9] memcg: per cgroup dirty page accounting
    On Mon, Mar 14, 2011 at 07:41:13PM -0700, Greg Thelen wrote:
    > On Mon, Mar 14, 2011 at 1:23 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
    > > On Mon, Mar 14, 2011 at 11:29:17AM -0700, Greg Thelen wrote:
    > >
    > > [..]
    > >> > We could just crawl the memcg's page LRU and bring things under control
    > >> > that way, couldn't we?  That would fix it.  What were the reasons for
    > >> > not doing this?
    > >>
    > >> My rational for pursuing bdi writeback was I/O locality.  I have heard that
    > >> per-page I/O has bad locality.  Per inode bdi-style writeback should have better
    > >> locality.
    > >>
    > >> My hunch is the best solution is a hybrid which uses a) bdi writeback with a
    > >> target memcg filter and b) using the memcg lru as a fallback to identify the bdi
    > >> that needed writeback.  I think the part a) memcg filtering is likely something
    > >> like:
    > >>  http://marc.info/?l=linux-kernel&m=129910424431837
    > >>
    > >> The part b) bdi selection should not be too hard assuming that page-to-mapping
    > >> locking is doable.
    > >
    > > Greg,
    > >
    > > IIUC, option b) seems to be going through pages of particular memcg and
    > > mapping page to inode and start writeback on particular inode?
    >
    > Yes.
    >
    > > If yes, this might be reasonably good. In the case when cgroups are not
    > > sharing inodes then it automatically maps one inode to one cgroup and
    > > once cgroup is over limit, it starts writebacks of its own inode.
    > >
    > > In case inode is shared, then we get the case of one cgroup writting
    > > back the pages of other cgroup. Well I guess that also can be handeled
    > > by flusher thread where a bunch or group of pages can be compared with
    > > the cgroup passed in writeback structure. I guess that might hurt us
    > > more than benefit us.
    >
    > Agreed. For now just writing the entire inode is probably fine.
    >
    > > IIUC how option b) works then we don't even need option a) where an N level
    > > deep cache is maintained?
    >
    > Originally I was thinking that bdi-wide writeback with memcg filter
    > was a good idea. But this may be unnecessarily complex. Now I am
    > agreeing with you that option (a) may not be needed. Memcg could
    > queue per-inode writeback using the memcg lru to locate inodes
    > (lru->page->inode) with something like this in
    > [mem_cgroup_]balance_dirty_pages():
    >
    > while (memcg_usage() >= memcg_fg_limit) {
    > inode = memcg_dirty_inode(cg); /* scan lru for a dirty page, then
    > grab mapping & inode */
    > sync_inode(inode, &wbc);
    > }

    Is it possible to pass mem_cgroup in writeback_control structure or in
    work structure which in turn will be set in writeback_control. And
    modify writeback_inodes_wb() which will look that ->mem_cgroup is
    set. So instead of calling queue_io() it can call memcg_queue_io()
    and then memory cgroup can look at lru list and take its own decision
    on which inodes needs to be pushed for IO?

    Thanks
    Vivek
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-03-15 22:27    [W:4.211 / U:0.604 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site