xfs
[Top] [All Lists]

Re: [PATCH 5/5] xfs: kick inode writeback when low on memory

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 5/5] xfs: kick inode writeback when low on memory
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 3 Mar 2011 10:48:19 -0500
Cc: chris.mason@xxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <20110303024228.GB15097@dastard>
References: <1298412969-14389-1-git-send-email-david@xxxxxxxxxxxxx> <1298412969-14389-6-git-send-email-david@xxxxxxxxxxxxx> <20110302030602.GD4905@dastard> <20110302141220.GA4363@xxxxxxxxxxxxx> <20110303024228.GB15097@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Mar 03, 2011 at 01:42:28PM +1100, Dave Chinner wrote:
> Yeah, it doesn't seem like there's an easy way around that. I guess
> I'll start by tracking VFS dirty inodes via a tag in the per-ag radix
> tree and kick writeback via a new xfssynd work operation. I'll see
> if that is sufficient to avoid the OOM problem without needing to
> log the inodes in the .dirty_inode callback or changing it's
> prototype.

I don't think we'll be able to get around chaning the dirty_inode
callback.  We need a way to prevent the VFS from marking the inode
dirty, otherwise we have no chance of reclaiming it.

Except for that I think it's really simple:

 1) we need to reintroduce the i_update_size flag or an equivalent to
    distinguish unlogged timestamp from unlogged size updates for fsync
    vs fdatasync.  At that point we can stop looking at the VFS dirty
    bits in fsync.
 2) ->dirty_inode needs to tag the inode as dirty in the inode radix
    tree

With those minimal changes we should be set - we already
callxfs_sync_attr from the sync_fs path, and xfs_sync_inode_attr
properly picks up inodes with unlogged changes.

In fact that whole scheme might even be able to speed up sync - right
now we first log the inode and then flush all pending data in the log
back to disk, and with this scheme we avoid logging the inode in the
first place.

<Prev in Thread] Current Thread [Next in Thread>