On Tue, Apr 13, 2010 at 02:40:35PM +0100, Mel Gorman wrote: > 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. As long as we keep the reclaimable separated from the "movable" that's fine. > 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. Only if the file isn't open... it's not really certain it's reclaimable. > 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. Awesome statistic! -- 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>