On Fri, Mar 29, 2019 at 04:45:58PM +0100, David Hildenbrand wrote: > 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. Right but we don't plan to do it yet. > Oh, and before I forget, different zones might of course also be a problem. I would just split the hint buffer evenly between zones. > > -- > > Thanks, > > David / dhildenb
