Re: [patch] real fix [Re: [patch] fixed 2.2.1 inode-leakage due bogus design of the free_inodes algo

Alexander Viro (viro@math.psu.edu)
Wed, 10 Feb 1999 09:23:06 -0500 (EST)


On Wed, 10 Feb 1999, Steve Dodd wrote:

> > Aside of that everything was pretty simple. From the VFS point of
> > view memory is freed from clean_inode() (inode.c). The same can be done
>
> clear_inode(), surely?
aaaaaaaarrrrghhh... Yes. Caffeine low, brain halted.
> Would it be possible to rename clean_inode() to
> blank_inode() or something, my brain keeps getting confused :)
>
> My point was that NTFS already hangs stuff off of the inode structure, but
> try_to_free_pages() doesn't know that it ought to clear the inode cache
> when looking for free pages; memory for the icache itself is never reclaimed
> and it doesn't shrink, but fs-specific allocs like NTFS does and ext2 will
> do might free memory.
Erm... AFACS NTFS offloads only part of stuff out of inode. Why,
BTW?
IMHO we need some mechanism that would allow using slabs from
modules. Then generic mechanisms would work quite fine. Maybe we would be
fine with request_slab(int size) that would keep a family of slabs, look
for one with the right object size in said family and create a new one if
not found. But then, I'm not a VM hacker (hint, hint).

> I still like the idea of having a list of functions to call to free memory.
Ahem... how will you deal with priorities?
Cheers,
Al

-
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/