Messages in this thread | | | Subject | Re: How long can an inode structure reside in the inode_cache? | From | Charlie Brett <> | Date | Mon, 12 Jun 2006 16:21:57 -0600 |
| |
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>
- 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/
| |