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