Re: Page allocator: Single Zone optimizations

[Christoph Lameter <clameter@sgi.com>]

On Fri, 3 Nov 2006, Mel Gorman wrote:

> > For now this would include reclaimable slabs?
> 
> It could, but I don't. Currently, only network buffers, inode caches, buffer
> heads and dentries are marked like this.

inode cache and dentries basically contain most of the reclaimable 
slab caches.

> > They are reclaimable with a
> > huge effort and there may be pinned objects that we cannot move. Isnt this
> > more another case of unmovable?
> 
> Probably, they would currently be treated as unmovable.

So you really do not currently need that section? If you drop the section 
then we have the same distinction that we wouild need for memory hotplug.

> > Note that memory for a loaded module is allocated via vmalloc, mapped via
> > a page table (init_mm) and thus memory is remappable. We will likely be
> > able to move those.
> > 
> 
> It's not just a case of updating init_mm. You would also need to tear down the
> vmalloc area for every current running process in the system in case they had
> faulted within that module. That would be pretty entertaining.

vmalloc areas are not process specific and this works just fine within the 
kernel. Eeek... remap_vmalloc_range() maps into user space. Need to have a 
list it seems to be able to also update those ptes.

> Once again, I am not adverse to writing such a defragment mechanism, but I see
> anti-frag as it currently stands as a prequisitie for a defragmentation
> mechanism having a decent success rate.

What you call anti-frag is really a mechanism to separate two different 
kinds of allocations that may be useful for multiple purposes not only 
anti-frag.

> Defragmentation on it's own would be insufficient for hugepage allocations
> because of unmovable pages dotted around the system. We know this because if
> you reclaim everything possible in the system, you still are unlikely to be
> able to grow the hugepage pool. If reclaiming everything doesn't give you huge
> pages, shuffling the same pages around the system won't improve the situation

It all depends on the movability of pages. If unmovable pages are 
sufficiently rare then this will work. 

I think we need something like what is done here via anti-frag but I wish 
it would be more generic and not solely rely on reclaim to get pages freed 
up.

Also the duplication of the page struct caches worries me because it 
reduces the hit rate. Removing the intermediate type would reduce the page 
caches to 2. And maybe we do not need caches for unreclaimable/unmovable 
pages? slab already does its own buffering there.

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