Message-ID: <0fdc41fb-b2ba-c6e6-36b9-97ad5a6eb54c@redhat.com>
Date:   Tue, 2 Apr 2019 20:53:32 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        Nitesh Narayan Lal <nitesh@...hat.com>,
        kvm list <kvm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        Paolo Bonzini <pbonzini@...hat.com>, lcapitulino@...hat.com,
        pagupta@...hat.com, wei.w.wang@...el.com,
        Yang Zhang <yang.zhang.wz@...il.com>,
        Rik van Riel <riel@...riel.com>, dodgen@...gle.com,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        dhildenb@...hat.com, Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: On guest free page hinting and OOM

>>> Why do we need them running in parallel for a single guest? I don't
>>> think we need the hints so quickly that we would need to have multiple
>>> VCPUs running in parallel to provide hints. In addition as it
>>> currently stands in order to get pages into and out of the buddy
>>> allocator we are going to have to take the zone lock anyway so we
>>> could probably just assume a single thread for pulling the memory,
>>> placing it on the ring, and putting it back into the buddy allocator
>>> after the hint has been completed.
>>
>> VCPUs hint when they think the time has come. Hinting in parallel comes
>> naturally.
> 
> Actually it doesn't because if we are doing it asynchronously we are
> having to pull pages out of the zone which requires the zone lock.

Yes, and we already work with zones already when freeing. At least one zone.

> That has been one of the reasons why the patches from Nitesh start
> dropping in performance when you start enabling more than 1 VCPU. If
> we are limited by the zone lock it doesn't make sense for us to try to
> do thing in parallel.

That is an interesting point and I'd love to see some performance numbers.

>>> Also there isn't a huge priority to report idle memory in real time.
>>> That would be kind of pointless as it might be pulled back out and
>>> reused as soon as it is added. What we need is to give the memory a
>>> bit of time to "cool" so that we aren't constantly hinting away memory
>>> that is still in use.
>>
>> Depending on the setup, you don't want free memory lying around for too
>> long in your guest.
> 
> Right, but you don't need it as soon as it is freed either. If it is
> idle in the guest for a few seconds that shouldn't be an issue. The
> free page hinting will hurt performance if we are doing it too often
> simply because we are going to be triggering a much higher rate of
> page faults.

Valid point.

> 
>>>
>>>> Your approach sounds very interesting to play with, however
>>>> at this point I would like to avoid throwing away Nitesh work once again
>>>> to follow some other approach that looks promising. If we keep going
>>>> like that, we'll spend another ~10 years working on free page hinting
>>>> without getting anything upstream. Especially if it involves more
>>>> core-MM changes. We've been there, we've done that. As long as the
>>>> guest-host interface is generic enough, we can play with such approaches
>>>> later in the guest. Important part is that the guest-host interface
>>>> allows for that.
>>>
>>> I'm not throwing anything away. One of the issues in Nitesh's design
>>> is that he is going to either miss memory and have to run an
>>> asynchronous thread to clean it up after the fact, or he is going to
>>> cause massive OOM errors and/or have to start halting VCPUs while
>>
>> 1. how are we going to miss memory. We are going to miss memory because
>> we hint on very huge chunks, but we all agreed to live with that for now.
> 
> What I am talking about is that some application frees gigabytes of
> memory. As I recall the queue length for a single cpu is only like 1G.
> Are we going to be sitting on the backlog of most of system memory
> while we process it 1G at a time?

I think it is something around "pages that fit into a request" *
"numbers of entries in a virtqueue".

> 
>> 2. What are the "massive OOM" errors you are talking about? We have the
>> one scenario we described Nitesh was not even able to reproduce yet. And
>> we have ways to mitigate the problem (discussed in this thread).
> 
> So I am referring to the last patch set I have seen. Last I knew all
> the code was doing was assembling lists if isolated pages and placing
> them on a queue. I have seen no way that this really limits the length
> of the virtqueue, and the length of the isolated page lists is the

Ah yes, we are discussing something towards possible capping in this
thread. Once there would be too much being hinted already, skip hinting
for now. Which might have good and bad sides. Different discussion.

> only thing that has any specific limits to it. So I see it easily
> being possible for a good portion of memory being consumed by the
> queue when you consider that what you have is essentially the maximum
> length of the isolated page list multiplied by the number of entries
> in a virtqueue.
> 
>> We have something that seems to work. Let's work from there instead of
>> scrapping the general design once more, thinking "it is super easy". And
>> yes, what you propose is pretty much throwing away the current design in
>> the guest.
> 
> Define "work"? The last patch set required massive fixes as it was
> causing kernel panics if more than 1 VCPU was enabled and list
> corruption in general. I'm sure there are a ton more bugs lurking as
> we have only begun to be able to stress this code in any meaningful
> way.

"work" - we get performance numbers that look promising and sorting out
issues in the design we find. This is RFC. We are discussing design
details. If there are issues in the design, let's discuss. If there are
alternatives, let's discuss. Bashing on the quality of prototypes?
Please don't.

> 
> For example what happens if someone sits on the mm write semaphore for
> an extended period of time on the host? That will shut down all of the
> hinting until that is released, and at that point once again any
> hinting queues will be stuck on the guest until they can be processed
> by the host.

I remember that is why we are using asynchronous requests. Combined with
dropping hints when in such a situation (posted hints not getting
processed), nobody would be stuck. Or am I missing something? Yes, then
the issue of dropped hints arises, and that is a different discussion.

> 
>>> waiting on the processing. All I am suggesting is that we can get away
>>> from having to deal with both by just walking through the free pages
>>> for the higher order and hinting only a few at a time without having
>>> to try to provide the host with the hints on what is idle the second
>>> it is freed.
>>>
>>>>>
>>>>> I view this all as working not too dissimilar to how a standard Rx
>>>>> ring in a network device works. Only we would want to allocate from
>>>>> the pool of "Buddy" pages, flag the pages as "Offline", and then when
>>>>> the hint has been processed we would place them back in the "Buddy"
>>>>> list with the "Offline" value still set. The only real changes needed
>>>>> to the buddy allocator would be to add some logic for clearing/merging
>>>>> the "Offline" setting as necessary, and to provide an allocator that
>>>>> only works with non-"Offline" pages.
>>>>
>>>> Sorry, I had to smile at the phrase "only" in combination with "provide
>>>> an allocator that only works with non-Offline pages" :) . I guess you
>>>> realize yourself that these are core-mm changes that might easily be
>>>> rejected upstream because "the virt guys try to teach core-MM yet
>>>> another special case". I agree that this is nice to play with,
>>>> eventually that approach could succeed and be accepted upstream. But I
>>>> consider this long term work.
>>>
>>> The actual patch for this would probably be pretty small and compared
>>> to some of the other stuff that has gone in recently isn't too far out
>>> of the realm of possibility. It isn't too different then the code that
>>> has already done in to determine the unused pages for virtio-balloon
>>> free page hinting.
>>>
>>> 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, a one-line change to the logic for
>>> allocating a page as we would need to clear that extra bit of state,
>>> and optionally some bits for how to handle the merge of two "Offline"
>>> pages in the buddy allocator (required for lower order support). It
>>> solves most of the guest side issues with the free page hinting in
>>> that trying to do it via the arch_free_page path is problematic at
>>> best since it was designed for a synchronous setup, not an
>>> asynchronous one.
>>
>> This is throwing away work. No I don't think this is the right path to
>> follow for now. Feel free to look into it while Nitesh gets something in
>> shape we know conceptually works and we are starting to know which
>> issues we are hitting.
> 
> Yes, it is throwing away work. But if the work is running toward a
> dead end does it add any value?

"I'm not throwing anything away. " vs. "Yes, it is throwing away work.",
now we are on the same page.

So your main point here is that you are fairly sure we are are running
towards an dead end, right?

> 
> I've been looking into the stuff Nitesh has been doing. I don't know
> about others, but I have been testing it. That is why I provided the
> patches I did to get it stable enough for me to test and address the
> regressions it was causing. That is the source of some of my concern.

Testing and feedback is very much appreciated. You have concerns, they
are valid. I do like discussing concerns, discussing possible solutions,
or finding out that it cannot be solved the easy way. Then throw it away.

Coming up with a clean design that considers problems that are not
directly visible is something I would like to see. But usually they
don't jump at you before prototyping.

The simplest approach so far was "scan for zero pages in the
hypervisor". No changes in the guest needed except setting pages to zero
when freeing. No additional threads in the guest. No hinting. And still
we decided against it.

> I think we have been making this overly complex with all the per-cpu
> bits and trying to place this in the free path itself. We really need

We already removed complexity, at least that is my impression. There are
bugs in there, yes.

> to scale this back and look at having a single thread with a walker of
> some sort just hinting on what memory is sitting in the buddy but not
> hinted on. It is a solution that would work, even in a multiple VCPU
> case, and is achievable in the short term.
Can you write up your complete proposal and start a new thread. What I
understood so far is

1. Separate hinting thread

2. Use virtio-balloon mechanism similar to Nitesh's work

3. Iterate over !offline pages in the buddy. Take them temporarily out
of the buddy (similar to Niteshs work). Send them to the hypervisor.
Mark them offline, put them back to the buddy.

4. When a page leaves the buddy, drop the offline marker.


Selected issues to be sorted out:
- We have to find a way to mask pages offline. We are effectively
touching pages we don't own (keeping flags set when returning pages to
the buddy). Core MM has to accept this change.
- We might teach other users how to treat buddy pages now. Offline
always has to be cleared.
- How to limit the cycles wasted scanning? Idle guests?
- How to efficiently scan a list that might always change between
hinting requests?
- How to avoid OOM that can still happen in corner cases, after all you
are taking pages out of the buddy temporarily.

-- 

Thanks,

David / dhildenb

Powered by blists - more mailing lists