Messages in this thread | | | Date | Wed, 10 Feb 1999 13:51:37 +0000 | From | Steve Dodd <> | Subject | Re: [patch] real fix [Re: [patch] fixed 2.2.1 inode-leakage due bogus design of the free_inodes algorithm |
| |
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/
| |