linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: Xin Zhao <uszhaoxin@gmail.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: How long can an inode structure reside in the inode_cache?
Date: Sat, 10 Jun 2006 15:01:27 -0400	[thread overview]
Message-ID: <448B1707.4090000@suse.com> (raw)
In-Reply-To: <4ae3c140606101012y6668fd5co7b7d2d453bb02397@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Xin Zhao wrote:
> No. I guess I didn't make my question clear.
> 
> My question is: Will an inode be released after the last file refers
> to this is closed? If so, this could bring a performance issue.
> Consider this case: a process open a file, read it, close it, then
> reopen this file, read it, close it. For every open,  the inode has to
> be read from disk again, which make hurt performance.
> 
> So I think inode should stay in inode_cache for a while, not released
> right after the last file stops referring it. I just want to know
> whether my guess is right. If it is, when will kernel release the
> inode, since an inode cannot stay in memory forever.

That's pretty much exactly what happens. The kernel caches inodes and
dentries when memory usage allows. When the last reference to an inode
is dropped and the file system is still in use, the inode goes on the
unused_inode list. It remains linked to the inode hash table. When a
inode is requested, the hash table is checked before trying to read it
back from disk. Check out generic_forget_inode() and ifind().

When there is memory pressure, the VM system will shrink these caches.
inode_init() registers a callback for the VM to call
shrink_icache_memory () which will finally free the memory. Check out
mm/vmscan.c and fs/inode.c for more detailed information.

- -Jeff

- --
Jeff Mahoney
SUSE Labs


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFEixcGLPWxlyuTD7IRAn1SAJ4yjgtJ9YL321W/18a7nttlaEc9pACeIMJX
yNUuC/impK4eZpHpLkwtCOQ=
=ykbS
-----END PGP SIGNATURE-----

  reply	other threads:[~2006-06-10 19:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-10  0:10 How long can an inode structure reside in the inode_cache? Xin Zhao
2006-06-10 12:13 ` Matthew Wilcox
2006-06-10 17:12   ` Xin Zhao
2006-06-10 19:01     ` Jeff Mahoney [this message]
2006-06-11  5:21       ` UZAIR LAKHANI
2006-06-11  5:35         ` Neil Brown
2006-06-12 18:20           ` How long can an inode structure reside in the inode_cache? - read the code Bryan Henderson
2006-06-12 23:28             ` Neil Brown
2006-06-13 23:25               ` Nate Diller
2006-07-05  0:41                 ` Andrew Morton

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=448B1707.4090000@suse.com \
    --to=jeffm@suse.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=uszhaoxin@gmail.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;
as well as URLs for NNTP newsgroup(s).