From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Nitesh Narayan Lal <nitesh@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, pbonzini@redhat.com, lcapitulino@redhat.com,
pagupta@redhat.com, wei.w.wang@intel.com,
yang.zhang.wz@gmail.com, riel@surriel.com, dodgen@google.com,
konrad.wilk@oracle.com, dhildenb@redhat.com, aarcange@redhat.com,
alexander.duyck@gmail.com
Subject: Re: On guest free page hinting and OOM
Date: Fri, 29 Mar 2019 12:51:26 -0400 [thread overview]
Message-ID: <20190329125034-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <f0ee075d-3e99-efd5-8c82-98d53b9f204f@redhat.com>
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
next prev parent reply other threads:[~2019-03-29 16:51 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-29 13:26 On guest free page hinting and OOM Michael S. Tsirkin
2019-03-29 14:24 ` David Hildenbrand
2019-03-29 15:08 ` Michael S. Tsirkin
2019-03-29 15:37 ` David Hildenbrand
2019-03-29 15:45 ` David Hildenbrand
2019-03-29 16:51 ` Michael S. Tsirkin [this message]
2019-04-01 8:17 ` David Hildenbrand
2019-04-01 13:24 ` Michael S. Tsirkin
2019-04-01 14:09 ` David Hildenbrand
2019-04-01 14:11 ` David Hildenbrand
2019-04-01 14:47 ` Michael S. Tsirkin
2019-04-01 14:54 ` David Hildenbrand
2019-04-01 20:56 ` Alexander Duyck
2019-04-02 7:42 ` David Hildenbrand
2019-04-02 15:04 ` Alexander Duyck
2019-04-02 15:25 ` Michael S. Tsirkin
2019-04-02 15:57 ` David Hildenbrand
2019-04-02 16:18 ` Alexander Duyck
2019-04-02 17:08 ` David Hildenbrand
2019-04-02 17:45 ` Alexander Duyck
2019-04-02 17:53 ` Michael S. Tsirkin
2019-04-02 20:32 ` Alexander Duyck
2019-04-02 18:21 ` David Hildenbrand
2019-04-02 19:49 ` Michael S. Tsirkin
2019-04-02 20:32 ` David Hildenbrand
2019-04-02 15:55 ` David Hildenbrand
2019-04-02 17:30 ` Alexander Duyck
2019-04-02 18:53 ` David Hildenbrand
2019-04-02 23:43 ` Alexander Duyck
2019-04-03 19:43 ` David Hildenbrand
2019-04-04 13:28 ` Michael S. Tsirkin
2019-04-02 16:19 ` David Hildenbrand
2019-04-01 14:45 ` Michael S. Tsirkin
2019-03-29 16:09 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190329125034-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=aarcange@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=david@redhat.com \
--cc=dhildenb@redhat.com \
--cc=dodgen@google.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nitesh@redhat.com \
--cc=pagupta@redhat.com \
--cc=pbonzini@redhat.com \
--cc=riel@surriel.com \
--cc=wei.w.wang@intel.com \
--cc=yang.zhang.wz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.