Thread (1 message) 1 message, 1 author, 2019-10-05

Re: VIRTIO_BALLOON_F_FREE_PAGE_HINT

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2019-10-05 21:03:11

On Fri, Oct 04, 2019 at 12:03:43PM -0700, Tyler Sanderson wrote:
I think DEFLATE_ON_OOM makes sense conceptually, it's just that the
implementation doesn't play well with the rest of memory management under
memory pressure.
It could probably be fixed with enough effort, but IMO free page hinting gets
90% of the benefit without poking the dark corners of memory management and so
is a net win.

The obvious place where free page hinting falls short (as David pointed out
above) is that it can't pressure the page cache.
Would it be possible to add a mechanism that explicitly causes page cache to
shrink without requiring the system to be under memory pressure?
Which API would you call to shrink it?

On Fri, Oct 4, 2019 at 1:56 AM David Hildenbrand [off-list ref] wrote:

    On 04.10.19 10:35, Michael S. Tsirkin wrote:
    > On Fri, Oct 04, 2019 at 10:06:03AM +0200, David Hildenbrand wrote:
    >> On 04.10.19 01:15, Tyler Sanderson wrote:
    >>> I was mistaken, the problem with overcommit accounting is not fixed by
    >>> the change to shrinker interface.
    >>> This means that large allocations are stopped even if they could
    succeed
    >>> by deflating the balloon.
    >>
    >> Please note that some people use the balloon for actual memory unplug -
    >> so initiating to deflate the balloon under any circumstances is
    >> undesired. It's different with "VIRTIO_BALLOON_F_DEFLATE_ON_OOM" being
    >> set - however that is barely the case (at least in the setups I know :)
    ).
    >>
    >> So yes, free page reporting is a different thing, because it really is
    >> used to "hint" and not to "agree to unplug" in any scenario.
    >>
    >> --
    >>
    >> Thanks,
    >>
    >
    >
    > VIRTIO_BALLOON_F_DEFLATE_ON_OOM isn't really well thought through
    > at the spec level either. For example, when will we inflate again?
    > Current code does this at the next interrupt, which requires
    > host to somehow know it's time to inflate.
    >

    The host has access to memory stats of the guest, so it could come up
    with some heuristics - but I do agree that is not well thought through -
    one reason why it is barely used :)

    --

    Thanks,

    David / dhildenb
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help