On Tue, Apr 13, 2010 at 03:31:54PM +0200, Andrea Arcangeli wrote: > Hi Neil! > > On Tue, Apr 13, 2010 at 04:18:02PM +1000, Neil Brown wrote: > > 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". > > I'm not sure if changing the slab object will make a whole lot of > difference, because antifrag will threat all unmovable stuff the > same. Anti-frag considers reclaimable slab caches to be different to unmovable allocations. Slabs with the SLAB_RECLAIM_ACCOUNT use the __GFP_RECLAIMABLE flag. It was to keep truly unmovable allocations in the same 2M pages where possible. It also means that even with large bursts of kernel allocations due to big filesystem loads, the system will still get some of those 2M blocks back eventually when slab eventually ages and shrinks. You can use /proc/pagetypeinfo to get a count of the 2M blocks of each type for different types of workloads to see what the scenarios look like from an anti-frag and compaction perspective but very loosly speaking, with compaction applied, you'd expect to be able to covert all "Movable" blocks to huge pages by either compacting or paging. You'll get some of the "Reclaimable" blocks if slab is shrunk enough the unmovable blocks depends on how many of the allocations are due to pagetables. > To make a difference directories should go in a different 2M > page of the inodes, and that would require changes to the slab code to > achieve I guess. > > However while I doubt it helps with hugepage fragmentation because of > the above, it still sounds a good idea to provide more "free memory" > to the system with less effort and while preserving more cache. > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>