Messages in this thread | | | Date | Wed, 10 Feb 1999 15:46:21 +0000 | From | Steve Dodd <> | Subject | icache, inodes & memory (was Re: [patch] fixed 2.2.1 inode-leakage due bogus design of the free_inodes algorithm) |
| |
On Wed, Feb 10, 1999 at 09:23:06AM -0500, Alexander Viro wrote:
> Erm... AFACS NTFS offloads only part of stuff out of inode. Why, > BTW?
Search me! I take no responsibility for it... I'm not really a kernel hacker at all.. I noticed the NTFS was Oopsing for me on a regular basis a while back, and as no-one here seemed particularly interested, I started reading the sources to figure out why.
> 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.
Err... Either I'm not understanding (more than likely) or we're talking at cross purposes. My point was that if you have allocated some memory which is associated with an inode, then clearing those inodes in the icache _may_ free memory, even though the icache itself never shrinks.
The slab allocator doesn't help here, I don't think.. kmem_cache_reap only reclaimed objects which are already free.. those objects wouldn't become free until the associated inodes were cleared.
> But then, I'm not a VM hacker (hint, hint).
*chuckles* You're talking to someone whose entire contribution to the kernel so far is some typo corrections in error messages and a couple of fiddles in the Makefile..:)
> > I still like the idea of having a list of functions to call to free memory. > Ahem... how will you deal with priorities?
typedef int (free_up_pages_func)(int priority, unsigned int gfpmask)
And maybe when you register the functions you specify another priority which specifies the order in which they get called, so some things which want to be a bit more 'clingy' about their memory can put up more of a struggle before giving it up. Actually, thinking about it I don't think that's needed...
Cheers, Steve
-- We are Linux. Resistance is an indication that you missed the point.
- 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/
| |