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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 13, 2010 at 03:44:56PM +0200, Andrea Arcangeli wrote:
> 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.
> 

That already happens.

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

True. Christoph made a few stabs at being able to slab targetted reclaim
(called defragmentation, but it was about reclaim) but it was never completed
and merged. Even if it was merged, the slab reclaimable objects would
still be kept in their own 2M pageblocks though.

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

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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]