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 <david@xxxxxxxxxx> 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 > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
