Re: [PATCH 00 of 41] Transparent Hugepage Support #17

[Neil Brown <neilb@suse.de>]

On Mon, 12 Apr 2010 20:38:29 -0400
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Mon, 12 Apr 2010 13:02:34 +0300 Avi Kivity <avi@redhat.com> wrote:
> 
> > The only scenario I can see where it degrades is that you have a dcache 
> > load that spills over to all of memory, then falls back leaving a pinned 
> > page in every huge frame.  It can happen, but I don't see it as a likely 
> > scenario.  But maybe I'm missing something.
> 
> <prehistoric memory>
> 
> This used to happen fairly easily.  You have a directory tree and some
> app which walks down and across it, stat()ing regular files therein. 
> So you end up with dentries and inodes which are laid out in memory as
> dir-file-file-file-file-...-file-dir-file-...  Then the file
> dentries/inodes get reclaimed and you're left with a sparse collection
> of directory dcache/icache entries - massively fragmented.
> 
> I forget _why_ it happened.  Perhaps because S_ISREG cache items aren't
> pinned by anything, but S_ISDIR cache items are pinned by their children
> so it takes many more expiry rounds to get rid of them.
> 
> There was talk about fixing this, perhaps by using different slab
> caches for dirs vs files.  Hard, because the type of the file/inode
> isn't known at allocation time.  Nothing happened about it.

Actually I don't think that would be hard at all.
->lookup can return a different dentry than the one passed in, usually using
d_splice_alias to find it.
So when you create an inode for a directory, create an anonymous dentry,
attach it via i_dentry, and it should "just work".
That is assuming this is still a "problem" that needs to be "fixed".

NeilBrown

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>