Re: [RFC PATCH v5 0/8] Make balloon drivers' memory changes known to the rest of the kernel

[Alexander Atanasov <alexander.atanasov@xxxxxxxxxxxxx>]

On 19.10.22 18:39, Konstantin Khlebnikov wrote:
> On Wed, 19 Oct 2022 at 14:06, Denis V. Lunev <den@xxxxxxxxxxxxx 
> <mailto:den@xxxxxxxxxxxxx>> wrote:
>     On 10/19/22 12:53, Konstantin Khlebnikov wrote:
>      > On Wed, 19 Oct 2022 at 12:57, Alexander Atanasov
>      > <alexander.atanasov@xxxxxxxxxxxxx
>     <mailto:alexander.atanasov@xxxxxxxxxxxxx>> wrote:
>      >
>      >     Currently balloon drivers (Virtio,XEN, HyperV, VMWare, ...)
>      >     inflate and deflate the guest memory size but there is no
>      >     way to know how much the memory size is changed by them.
>      >
>      >     Make it possible for the drivers to report the values to mm core.
>      >
>      >     Display reported InflatedTotal and InflatedFree in /proc/meminfo
>      >     and print these values on OOM and sysrq from show_mem().
>      >
>      >     The two values are the result of the two modes the drivers work
>      >     with using adjust_managed_page_count or without.
>      >
>      >     In earlier versions, there was a notifier for these changes
>      >     but after discussion - it is better to implement it in separate
>      >     patch series. Since it came out as larger work than initially
>      >     expected.
>      >
>      >     Amount of inflated memory can be used:
>      >      - totalram_pages() users working with drivers not using
>      >         adjust_managed_page_count
>      >      - si_meminfo(..) users can improve calculations
>      >      - by userspace software that monitors memory pressure
>      >
>      >
>      > Sorry, I see no reason for that series.
>      > Balloon inflation adjusts totalram_pages. That's enough.
>      >
>     no, they are not at least under some circumstances, f.e.
>     virtio balloon does not do that with VIRTIO_BALLOON_F_DEFLATE_ON_OOM
>     set
>
>
>      > There is no reason to know the amount of non-existent ballooned
>     memory
>      > inside.
>      > Management software which works outside should care about that.
>      >
>     The problem comes at the moment when we are running
>     our Linux server inside virtual machine and the customer
>     comes with crazy questions "where our memory?".
>
>
> Ok. In this case balloon management is partially inside VM.
> I.e. we could report portion of balloon as potentially available memory.
>
> I guess memory pressure could deflate balloon till some threshold set by 
> external hypervisor.
> So, without knowledge about this threshold there is no correct answer 
> about size of available memory.
> Showing just size of balloon doesn't gives much.
You need the current and the adjustment to get the absolute top.
If you check only totalram_pages() it is the current. To get the 
absolute maximum you need to know how much the balloon adjusted it.
The drivers that do not adjust totalram_pages() and leave the inflated 
memory as used assume that this memory can be reclaimed at anytime.
But that assumption is not completely true and provides the system with 
false totalram value. Why - VMWare does not have oom_notifier at all (it 
is possible to have sone other mechanism, i do not know), Virtio balloon 
reclaims 1MB on OOM _if_ it can.
--
Regards,
Alexander Atanasov