> On Wed, 10 Feb 1999, Steve Dodd wrote:
>
> >Hi,
> >
> >On Fri, Feb 05, 1999 at 12:46:43AM +0100, Andrea Arcangeli wrote:
> >
> >> free_inode_memory() is ok to not be recalled from try_to_free_pages()
> >> because it can't generate more free memory but only more clean inode to
> >> reuse in the filesystem so only the fs must call it when get_new_inode()
> >> or something similar fails.
> >
> >Except in NTFS (I think), where clea{r,n}ing an inode frees up some memory
> >allocated specifically by the file system.
>
> Again: free_inode_memory() don't generate free memory: it _only_ move
> inodes from one list to another list.
>
> Could you show me the code you think is freeing memory?
D'oh. Code in question is in filesystems. Look: suppose you want to
allocate a data associated with inode. You will do it from read_inode()
and on inode creation, all right, but where will you free it? The *only*
resonable place being ->clear_inode() method. And it's called by
fs/inode.c::clear_inode(). Called by fs/inode.c::dispose_list(). Called
by fs/inode.c::free_inodes(). Called by fs/inode.c::free_inode_memory().
See the path now?
Again, it doesn't free inode memory per se. But for some inodes it
informs filesystems that they should free their internal data associated
with said inodes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/