From: Charlie Brett <cfb@hp.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: How long can an inode structure reside in the inode_cache?
Date: Mon, 12 Jun 2006 16:21:57 -0600 [thread overview]
Message-ID: <1150150917.5631.77.camel@localhost.localdomain> (raw)
In-Reply-To: <4ae3c140606091710k7a320f2ex6390d0e01da4de9b@mail.gmail.com>
On Fri, 2006-06-09 at 20:10 -0400, Xin Zhao wrote:
> I was wondering how Linux decide to free an inode from the
> inode_cache? If a file is open, an inode structure will be created and
> put into the inode_cache, but when will this inode be free and removed
> from the inode_cache? after this file is closed? If so, this seems to
> be inefficient.
>
> Can someone tell me how Linux handle this issue?
>
> Thanks,
> Xin
As already pointed out, in the simplest case, an inode is removed from
the in_use list and marked free in the cache when the last user closes
it. There are certain situations where the inode cannot be marked free
right away, because of references to it. In those cases, the inode will
end up on the unused list, and will eventually get marked free in the
inode cache by kswapd when the system is low on free memory.
Now if your question is really, "When does the memory occupied by the
inode get released to the general memory pool?", then the answer is when
all the inodes of a cache page are marked free and kswapd returns the
entire page to the memory pool.
The whole process is not that inefficient, since memory is not
"recovered" until there is a need for it. Odds are, if memory was used
for a given type of cache, it will probably be needed again for the same
thing. The only problem that could occur is when there are a lot of
partially filled cache pages (e.g. pages that only contain a very few
number of objects). It does happen, but I think it's pretty rare.
If you do get into a situation where you think your system is spending a
lot of time trying to recover memory (perhaps because it has a large
amount of icache allocated), you could try running a process that
requires a large amount of memory, which would force recovery. Then,
when the process terminates, the memory would be released. This doesn't
change the behavior, but makes it a bit more predictable.
--
Charlie Brett <cfb@hp.com>
prev parent reply other threads:[~2006-06-12 22:06 UTC|newest]
Thread overview: 6+ 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 5:32 ` Bernd Eckenfels
2006-06-10 12:13 ` Matthew Wilcox
2006-06-10 17:12 ` Xin Zhao
2006-06-10 19:01 ` Jeff Mahoney
2006-06-12 22:21 ` Charlie Brett [this message]
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=1150150917.5631.77.camel@localhost.localdomain \
--to=cfb@hp.com \
--cc=linux-kernel@vger.kernel.org \
/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