n Tue, Apr 2, 2019 at 8:57 AM David Hildenbrand <david@xxxxxxxxxx> wrote: > > On 02.04.19 17:25, Michael S. Tsirkin wrote: > > On Tue, Apr 02, 2019 at 08:04:00AM -0700, Alexander Duyck wrote: > >> Basically what we would be doing is providing a means for > >> incrementally transitioning the buddy memory into the idle/offline > >> state to reduce guest memory overhead. It would require one function > >> that would walk the free page lists and pluck out pages that don't > >> have the "Offline" page type set, > > > > I think we will need an interface that gets > > an offline page and returns the next online free page. > > > > If we restart the list walk each time we can't guarantee progress. > > Yes, and essentially we are scanning all the time for chunks vs. we get > notified which chunks are possible hinting candidates. Totally different > design. The problem as I see it is that we can miss notifications if we become too backlogged, and that will lead to us having to fall back to scanning anyway. So instead of trying to implement both why don't we just focus on the scanning approach. Otherwise the only other option is to hold up the guest and make it wait until the hint processing has completed and at that point we are back to what is essentially just a synchronous solution with batching anyway.
