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

Steve Dodd (dirk@loth.demon.co.uk)
Wed, 10 Feb 1999 13:51:37 +0000


Hi,

On Wed, Feb 10, 1999 at 08:06:47AM -0500, Alexander Viro wrote:

> Erm... In my tree - yes. But not in the mainstream kernel. Wait till 2.3.

Ah, I see.

> 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? 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.

I'm seeing the NTFS driver running out of memory because of this (I think).

The other thing we probably need to do is patch the slab allocator; at the
moment if there are no free objects in the cache, it attempts to grow the
cache; this tries to get a free page, which calls try_to_free_pages(); though
this may not free a whole page, it may result in kfree()s which free objects,
so even if growing the cache fails, we should check once more to see if there
is a free object.

I still like the idea of having a list of functions to call to free memory.
At the moment there is no way that, say, a driver which allocates memory for
cache can shrink its cache it low-memory situations, if it is a module. And
even if it isn't, it still needs a kludge in vmscan.c.

I think.

Cheers,
Steve

-- 
%DCL-MEM-BAD, bad memory
VMS-F-PDGERS, pudding between the ears

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