Re: Page allocator: Single Zone optimizations

[Christoph Lameter <clameter@sgi.com>]

On Fri, 3 Nov 2006, Mel Gorman wrote:

> I know, this sort of thing would have to be written into page migration before
> defrag for high-order allocations was developed. Even then, defrag needs to
> sit on top of something like anti-frag to get teh clustering of movable pages.

Hmmm... The disk defraggers are capable of defragmenting around pinned 
blocks and this seems to be a similar. This only works if the number of 
unmovable objects is small compared to the movable objects otherwise we 
may need this sorting.  For other reasons discussed before (memory unplug, 
node unplug) I think it would be necessary to have this separation 
between movable and unmovable pages.

I can add a migrate_page_table_page() function? The migrate_pages() 
function is only capable of migrating user space pages since it relies on 
being able to take pages off the LRU. At some point we need to 
distinguishthe type of page and call the appropriate migration function 
for the various page types.

int migrate_page_table_page(struct page *new, struct page *new);
?

> Reclaimable - These are kernel allocations for caches that are
>         reclaimable or allocations that are known to be very short-lived.
> 	These allocations are marked __GFP_RECLAIMABLE

For now this would include reclaimable slabs? They are reclaimable with a 
huge effort and there may be pinned objects that we cannot move. Isnt this 
more another case of unmovable? Or can we tolerate the objects that cannot 
be moved and classify this as movable (with the understanding that we may 
have to do expensive slab reclaim (up to dropping all reclaimable slabs) 
in order to get there).

> Non-Movable - These are pages that are allocated by the kernel that
>         are not trivially reclaimed. For example, the memory allocated for a
>         loaded module would be in this category. By default, allocations are
>         considered to be of this type
> 	These are allocations that are not marked otherwise

Ok.

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.

> So, right now, page tables would not be marked __GFP_MOVABLE, but they would
> be later when defrag was developed. Would that be any better?

Isnt this is still doing reclaim instead of defragmentation? Maybe it 
will work but I am not not sure about the performance impact. We 
would have to read pages back in from swap or disk?

The problem that we have is that one cannot higher order pages since 
memory is fragmented. Maybe what would initially be sufficient is that a failing 
allocation of a higher order page lead to defrag occurring until pages of 
suffiecient size have been created and then the allocation can be satisfied.

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