Re: [RFC] Hugepage collapse in process context

[Michal Hocko <mhocko@suse.com>]

[Cc linux-api]

On Tue 16-02-21 20:24:16, David Rientjes wrote:
> Hi everybody,
> 
> Khugepaged is slow by default, it scans at most 4096 pages every 10s.  
> That's normally fine as a system-wide setting, but some applications would 
> benefit from a more aggressive approach (as long as they are willing to 
> pay for it).
> 
> Instead of adding priorities for eligible ranges of memory to khugepaged, 
> temporarily speeding khugepaged up for the whole system, or sharding its 
> work for memory belonging to a certain process, one approach would be to 
> allow userspace to induce hugepage collapse.
> 
> The benefit to this approach would be that this is done in process context 
> so its cpu is charged to the process that is inducing the collapse.  
> Khugepaged is not involved.

Yes, this makes a lot of sense to me.

> Idea was to allow userspace to induce hugepage collapse through the new 
> process_madvise() call.  This allows us to collapse hugepages on behalf of 
> current or another process for a vectored set of ranges.

Yes, madvise sounds like a good fit for the purpose.

> This could be done through a new process_madvise() mode *or* it could be a 
> flag to MADV_HUGEPAGE since process_madvise() allows for a flag parameter 
> to be passed.  For example, MADV_F_SYNC.

Would this MADV_F_SYNC be applicable to other madvise modes? Most
existing madvise modes do not seem to make much sense. We can argue that
MADV_PAGEOUT would guarantee the range was indeed reclaimed but I am not
sure we want to provide such a strong semantic because it can limit
future reclaim optimizations.

To me MADV_HUGEPAGE_COLLAPSE sounds like the easiest way forward.
-- 
Michal Hocko
SUSE Labs