Re: Atrocious icache/dcache in 2.4.2

From: Christoph Hellwig (
Date: Fri Apr 27 2001 - 14:13:37 EST

Hi Pete,

In article <> you wrote:
> After a little thinking it seems apparent to me that it
> may be a good thing to have VM taking pages from dentry and
> inode pools directly. This sounds almost what slab does,
> so let me speculate about it (it is a bad idea, but it is
> interesting _why_).
> Suppose that we do this: when inode gets clean (e.g. unlocked,
> written to disk if was changed), drop it into kmem_cache_free(),
> but retain on hash (forget about poisoning for a momemt).
> Then, if memory is needed, VM may ask slab, slab calls our
> destructors, and destructors take inode off hash. The idea
> solves the problem, but has two marks agains it. First, when
> we look up an inode, we either hit dirty or "clean", which
> is free. Then we have to do kmem_cache_alloc() and that will
> return wrong inode, which we have to drop from hash, then do
> memcpy from old "really free one", etc. It still saves disk
> I/O, but messy. Another thing is a fragmentation: suppose we
> have bunch of slabs, every one has a single dirty inode in it
> (tar xf -). Memory pressure will be powerless to do anything
> about them.

It looks like you want the SLAB cache ->reclaim method we seem
to have forgotten when cloning the Solaris SLAB interface nearly


Of course it doesn't work. We've performed a software upgrade.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:18 EST