On 29.03.19 16:37, David Hildenbrand wrote: > On 29.03.19 16:08, Michael S. Tsirkin wrote: >> On Fri, Mar 29, 2019 at 03:24:24PM +0100, David Hildenbrand wrote: >>> >>> We had a very simple idea in mind: As long as a hinting request is >>> pending, don't actually trigger any OOM activity, but wait for it to be >>> processed. Can be done using simple atomic variable. >>> >>> This is a scenario that will only pop up when already pretty low on >>> memory. And the main difference to ballooning is that we *know* we will >>> get more memory soon. >> >> No we don't. If we keep polling we are quite possibly keeping the CPU >> busy so delaying the hint request processing. Again the issue it's a > > You can always yield. But that's a different topic. > >> tradeoff. One performance for the other. Very hard to know which path do >> you hit in advance, and in the real world no one has the time to profile >> and tune things. By comparison trading memory for performance is well >> understood. >> >> >>> "appended to guest memory", "global list of memory", malicious guests >>> always using that memory like what about NUMA? >> >> This can be up to the guest. A good approach would be to take >> a chunk out of each node and add to the hints buffer. > > This might lead to you not using the buffer efficiently. But also, > different topic. > >> >>> What about different page >>> granularity? >> >> Seems like an orthogonal issue to me. > > It is similar, yes. But if you support multiple granularities (e.g. > MAX_ORDER - 1, MAX_ORDER - 2 ...) you might have to implement some sort > of buddy for the buffer. This is different than just a list for each node. Oh, and before I forget, different zones might of course also be a problem. -- Thanks, David / dhildenb
