Re: VM deadlock

From: Andrew Morton (andrewm@uow.edu.au)
Date: Wed Jun 27 2001 - 22:21:28 EST


Chris Mason wrote:
>
> ...
> The work around I've been using is the dirty_inode method. Whenever
> mark_inode_dirty is called, reiserfs logs the dirty inode. This means
> inode changes are _always_ reflected in the buffer cache right away, and
> the inode itself is never actually dirty.

reiserfs_mark_inode_dirty() has taken a copy of the in-core inode, so
it can do this:

            spin_lock(&inode_lock);
            if ((inode->i_state & I_LOCK) == 0)
                    inode->i_state &= ~(I_DIRTY_SYNC|I_DIRTY_DATASYNC);
            spin_unlock(&inode_lock);

Unfortunately there is no API function to do this, so inode_lock
needs to be exported :(

The effect of this is that the filesystem almost never has dirty inodes
as far as the VFS is concerned: shrink_icache_memory() can just drop the
inodes without calling into the fs at all. Which is nice.

So you end up with:

reiserfs_write_inode(struct inode * inode, int do_sync)
{
}

The write_inode() method is still called by shrink_icache_memory()
with extreme infrequency. I haven't looked into the reasons why. It may
be an SMP window.

This is not just a memory-tweak-optimisation hack, BTW.
shrink_icache->write_inode is a horrible embarrassment because it
can be called at any time. The caller may have a transaction open
against a different fs. It would cause nested transactions which
will exceed the current reservation, which will require a commit,
which simply cannot be performed, etc.

sync(), fsync() and msync() can be handled in ->fsync().

-
-
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/



This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:18 EST