From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Cc: linux-fsdevel@vger.kernel.org
Subject: [PATCH 0/5] Combine the XFS and Linux inode structures V2
Date: Wed, 8 Oct 2008 08:52:07 +1100 [thread overview]
Message-ID: <1223416332-7026-1-git-send-email-david@fromorbit.com> (raw)
XFS currently has to deal with two separate inode lifecycles
which makes for complexity in inode lookups and reclaim. We
also have the problem of not always having a linux inode around
when it might be useful to have it.
To avoid these lifecycle problems, this series embedѕ the linux
inode inside the struct xfs_inode and changes the way we reference
the two inodes. We can no longer check for a null linux inode -
instead we have to check to see if it is valid or not by checking
either the linux inode or xfs inode state flags. While this means
that inodes waiting for reclaim use more memory, this is not the
common state for inodes and they will soon be completely freed so
the additional memeory use in this state is only temporary.
This combining of the inodes simplifies the inode and reclaim logic,
making it possible to do reclaim via radix tree tags (an upcoming
patch series) and to be able to use RCU locking on the radix trees.
The fact that we don't have a simple mechanism to determine the
reclaim state of the inode makes RCU locking very complex, and this
complexity is removed by having a combined inode structure.
This patch series also changes the way XFS caches inodes. It no
longer uses the linux inode cache as the primary lookup cache -
instead we rely solely on the XFS inode caches. This avoids the
inode_lock in lookups that hit the cache - we should get much
better parallelism out of inode lookup than we currently do now.
In future, we should also be able to cull duplicate fields out of
the xfs and linux inodes reducing the overall memory usage of
the active inode cache. This provides scope for continuing to
reduce the memory footprint of the XFS inode cache.
Version 2:
o clean up based on review comments
o pull preparation patches into series now there's only two
uncommitted patches.
next reply other threads:[~2008-10-07 21:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-07 21:52 Dave Chinner [this message]
2008-10-07 21:52 ` [PATCH 1/5] XFS: factor xfs_iget_core() into hit and miss cases Dave Chinner
2008-10-07 21:52 ` [PATCH 2/5] XFS: Never call mark_inode_dirty_sync() directly Dave Chinner
2008-10-07 21:52 ` [PATCH 3/5] Inode: Allow external initialisers Dave Chinner
2008-10-14 7:00 ` Lachlan McIlroy
2008-10-14 6:53 ` Dave Chinner
2008-10-14 12:55 ` Christoph Hellwig
2008-10-15 1:09 ` Lachlan McIlroy
2008-10-07 21:52 ` [PATCH 4/5] Inode: Allow external list initialisation Dave Chinner
2008-10-07 21:52 ` [PATCH 5/5] XFS: Combine the XFS and Linux inodes V3 Dave Chinner
2008-10-09 4:21 ` [PATCH 6/5]: XFS: Prevent use-after-free caused by synchronous inode reclaim Dave Chinner
2008-10-09 7:02 ` Christoph Hellwig
2008-10-09 8:07 ` 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=1223416332-7026-1-git-send-email-david@fromorbit.com \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--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