Re: Page allocator: Single Zone optimizations

[Andy Whitcroft <apw@shadowen.org>]

>> An intemediate step that would make sense is starting to
>> marking pages as unmovable and then reclaim movable pages. Then we can
>> add
>> more and more logic to make move pages movable on top. With marking
>> pages for reclaim we wont get there.
>>
> 
> Ok, I can make that renaming change now so. The renaming will look like
> 
> Movable - These are userspace pages that are easily moved. This
>         flag is set when it is known that the pages will be trivially
>     moved by using page migration or if under significant
>     memory pressure, writing the page out to swap or syncing with
>     backing storage
>     These allocations are marked with __GFP_MOVABLE
> 
> 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
> 
> 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
> 
> 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?

Ok, as far as I can tell you are both describing the same basic thing
with different names.

The key problem here is we want to be able to allocate non-order zero
pages, where there are such pages available all is well.  When there are
not we need to look for a group of contiguous 'emptyable' pages; and
recycle them.  This is the key, we do not care what is in them, only
whether we can get whatever it is out to release a single contiguous
block.  We do not care what the mechanism for that is, release, move or
even swap them.  The attribute of the memory is whether its pinned or
not, whether the page is emptyable.  We want to make sure we keep
emptyable pages with other emptyable pages so that our chances of
finding a higher order block emptyable is likely.

We currently talk about the act of selecting pages for release as
reclaim.  We should not get too caught up in thinking of that as
removing things from memory.  Yes, right now the only time we use
reclaim is when we do not have any free memory, and so its only goal is
to remove things from memory -- that is a side effect of it only
supporting order 0 reclaim, moving a page there is mostly useless.
Supporting higher order reclaim we might start reclaim at order 1 with
50% of memory free.  In this case the reclaim strategy could and should
include the option to relocate the relocatable memory object.

Now perhaps 'EMPTYABLE', 'RELEASABLE' or 'RECYCLABLE' is more
appropriate than 'RECLAIMABLE', but its not at all clear that 'MOVABLE'
is better.  Moving pages is but one strategy 'reclaim' could use to
achieve its aim, getting us the memory block we asked for.

I do not see how any of what Mel is saying precludes the use of
migration as a reclaim mechanism allowing more things to be placed in
the 'emptyable' set rather than the 'pinned' set.

-apw

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