Re: [Lsf] IO less throttling and cgroup aware writeback

Dave Chinner
2011-04-07T23:42:54Z

On Thu, Apr 07, 2011 at 03:24:24PM -0400, Vivek Goyal wrote:
> On Thu, Apr 07, 2011 at 09:36:02AM +1000, Dave Chinner wrote:
[...]
> > > When I_DIRTY is cleared, remove inode from bdi_memcg->b_dirty. Delete bdi_memcg
> > > if the list is now empty.
> > >
> > > balance_dirty_pages() calls mem_cgroup_balance_dirty_pages(memcg, bdi)
> > > if over bg limit, then
> > > set bdi_memcg->b_over_limit
> > > If there is no bdi_memcg (because all inodes of current’s
> > > memcg dirty pages where first dirtied by other memcg) then
> > > memcg lru to find inode and call writeback_single_inode().
> > > This is to handle uncommon sharing.
> >
> > We don't want to introduce any new IO sources into
> > balance_dirty_pages(). This needs to trigger memcg-LRU based bdi
> > flusher writeback, not try to write back inodes itself.
>
> Will we not enjoy more sequtial IO traffic once we find an inode by
> traversing memcg->lru list? So isn't that better than pure LRU based
> flushing?

Sorry, I wasn't particularly clear there, What I meant was that we
ask the bdi-flusher thread to select the inode to write back from
the LRU, not do it directly from balance_dirty_pages(). i.e.
bdp stays IO-less.

> > Alternatively, this problem won't exist if you transfer page щache
> > state from one memcg to another when you move the inode from one
> > memcg to another.
>
> But in case of shared inode problem still remains. inode is being written
> from two cgroups and it can't be in both the groups as per the exisiting
> design.

But we've already determined that there is no use case for this
shared inode behaviour, so we aren't going to explictly support it,
right?

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html