Re: Balloon pressuring page cache

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 04, 2020 at 10:52:42AM -0800, Tyler Sanderson wrote:
> 
> 
> On Tue, Feb 4, 2020 at 12:29 AM David Hildenbrand <david@redhat.com> wrote:
> 
>     On 03.02.20 21:32, Tyler Sanderson wrote:
>     > There were apparently good reasons for moving away from OOM notifier
>     > callback:
>     > https://lkml.org/lkml/2018/7/12/314
>     > https://lkml.org/lkml/2018/8/2/322
>     >
>     > In particular the OOM notifier is worse than the shrinker because:
> 
>     The issue is that DEFLATE_ON_OOM is under-specified.
> 
>     >
>     >  1. It is last-resort, which means the system has already gone through
>     >     heroics to prevent OOM. Those heroic reclaim efforts are expensive
>     >     and impact application performance.
> 
>     That's *exactly* what "deflate on OOM" suggests.
> 
> 
> It seems there are some use cases where "deflate on OOM" is desired and others
> where "deflate on pressure" is desired.
> This suggests adding a new feature bit "DEFLATE_ON_PRESSURE" that registers the
> shrinker, and reverting DEFLATE_ON_OOM to use the OOM notifier callback.
> 
> This lets users configure the balloon for their use case.

Right. Let's not repeat past mistakes and let's try to specify this
new one properly though :)

> 
> 
>     Assume you are using virtio-balloon for some weird way of memory
>     hotunplug (which is what some people do) and you want to minimize the
>     footprint of your guest. Then you really only want to give the guest
>     more memory (or rather, let it take back memory automatically in this
>     case) in case it really needs more memory. It should try to reclaim first.
> 
>     Under-specified.
> 
> 
>     >  2. It lacks understanding of NUMA or other OOM constraints.
> 
>     Ballooning in general lacks the understanding of NUMA.
> 
>     >  3. It has a higher potential for bugs due to the subtlety of the
>     >     callback context.
> 
>     While that is a valid point, it doesn't explain why existing
>     functionality is changed.
> 
>     Personally, I think DEFLATE_ON_OOM should never have been introduced (at
>     least not in this form).
> 
> I'm actually not sure how you would safely do memory overcommit without
> DEFLATE_ON_OOM. So I think it unlocks a huge use case.
>  
> 
> 
> 
>     --
>     Thanks,
> 
>     David / dhildenb
> 
>