From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: chris.mason@oracle.com, xfs@oss.sgi.com
Subject: Re: [PATCH 5/5] xfs: kick inode writeback when low on memory
Date: Thu, 3 Mar 2011 10:48:19 -0500 [thread overview]
Message-ID: <20110303154819.GA3945@infradead.org> (raw)
In-Reply-To: <20110303024228.GB15097@dastard>
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.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-03-03 15:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 22:16 [RFC, PATCH 0/5] xfs: Reduce OOM kill problems under heavy load Dave Chinner
2011-02-22 22:16 ` [PATCH 1/5] xfs: introduce inode cluster buffer trylocks for xfs_iflush Dave Chinner
2011-03-03 15:55 ` Christoph Hellwig
2011-03-03 22:04 ` Dave Chinner
2011-02-22 22:16 ` [PATCH 2/5] xfs: introduce a xfssyncd workqueue Dave Chinner
2011-02-22 22:16 ` [PATCH 3/5] xfs: convert ENOSPC inode flushing to use new syncd workqueue Dave Chinner
2011-03-03 15:34 ` Christoph Hellwig
2011-03-03 22:41 ` Dave Chinner
2011-03-04 12:40 ` Christoph Hellwig
2011-02-22 22:16 ` [PATCH 4/5] xfs: introduce background inode reclaim work Dave Chinner
2011-03-03 15:36 ` Christoph Hellwig
2011-03-03 22:43 ` Dave Chinner
2011-02-22 22:16 ` [PATCH 5/5] xfs: kick inode writeback when low on memory Dave Chinner
2011-03-02 3:06 ` Dave Chinner
2011-03-02 14:12 ` Christoph Hellwig
2011-03-03 2:42 ` Dave Chinner
2011-03-03 15:48 ` Christoph Hellwig [this message]
2011-03-03 16:19 ` Christoph Hellwig
2011-03-09 5:46 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110303154819.GA3945@infradead.org \
--to=hch@infradead.org \
--cc=chris.mason@oracle.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox