Re: [PATCH] mm: split thp synchronously on MADV_DONTNEED

[David Hildenbrand]

On 20.11.21 21:12, Shakeel Butt wrote:
> Many applications do sophisticated management of their heap memory for
> better performance but with low cost. We have a bunch of such
> applications running on our production and examples include caching and
> data storage services. These applications keep their hot data on the
> THPs for better performance and release the cold data through
> MADV_DONTNEED to keep the memory cost low.
> 
> The kernel defers the split and release of THPs until there is memory
> pressure. This causes complicates the memory management of these
> sophisticated applications which then needs to look into low level
> kernel handling of THPs to better gauge their headroom for expansion.

Can you elaborate a bit on that point? What exactly does such an
application do? I would have assumed that it's mostly transparent for
applications.

> In
> addition these applications are very latency sensitive and would prefer
> to not face memory reclaim due to non-deterministic nature of reclaim.

That makes sense.

> 
> This patch let such applications not worry about the low level handling
> of THPs in the kernel and splits the THPs synchronously on
> MADV_DONTNEED.

The main user I'm concerned about is virtio-balloon, which ends up
discarding VM memory via MADV_DONTNEED when inflating the balloon in the
guest in 4k granularity, but also during "free page reporting"
continuously when e.g., a 2MiB page becomes free in the guest. We want
both activities to be fast, and especially during "free page reporting",
to defer any heavy work.

Do we have a performance evaluation how much overhead is added e.g., for
a single 4k MADV_DONTNEED call on a THP or on a MADV_DONTNEED call that
covers the whole THP?

-- 
Thanks,

David / dhildenb