All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Wang <wei.w.wang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: penguin-kernel@I-love.SAKURA.ne.jp, linux-mm@kvack.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, mhocko@kernel.org
Subject: Re: [PATCH v1 3/3] virtio-balloon: stop inflating when OOM occurs
Date: Tue, 24 Oct 2017 09:58:36 +0800	[thread overview]
Message-ID: <59EE9E4C.3030207__45861.8061071776$1508810219$gmane$org@intel.com> (raw)
In-Reply-To: <20171022062159-mutt-send-email-mst@kernel.org>

On 10/23/2017 01:13 AM, Michael S. Tsirkin wrote:
> On Fri, Oct 20, 2017 at 07:54:26PM +0800, Wei Wang wrote:
>> This patch forces the cease of the inflating work when OOM occurs.
>> The fundamental idea of memory ballooning is to take out some guest
>> pages when the guest has low memory utilization, so it is sensible to
>> inflate nothing when the guest is already under memory pressure.
>>
>> On the other hand, the policy is determined by the admin or the
>> orchestration layer from the host. That is, the host is expected to
>> re-start the memory inflating request at a proper time later when
>> the guest has enough memory to inflate, for example, by checking
>> the memory stats reported by the balloon.
> Is there any other way to do it? And if so can't we just have guest do
> it automatically? Maybe the issue is really that fill attempts to
> allocate memory aggressively instead of checking availability.
> Maybe with deflate on oom it should check availability?
>

I think it might not be easy to do it in the guest in practice.
For example, the host asks for 4G from the guest, and the guest checks
that it has 4G that can be inflated at that point. While it is inflating 
and 2G
is done inflating, another new task on the guest comes out and
takes the remaining 2G to use. Now the guest has nothing to inflate.

This would raise the questions:
1) what is the point of checking the availability?
Maybe we could just let the guest inflate as much as it can, that is, till
balloon_page_enqueue() returns NULL, then stop inflating.

2) How long would the host has to wait for this guest to get the 
remaining 2G?
If I understand "guest do it automatically" correctly: now the guest is 
responsible
for giving another 2G, which he owes to the host in this case - not 
giving up inflating
whenever there is some free memory. Maybe in the next 1 hour it wouldn't 
have any
memory available to give to the host. The time seems non-deterministic.

If we leave it to the host to define the policy, I think it would be easier.
Once the host finds that the guest can only offer 2G, then it can just 
give up asking
for memory from this guest, and continue to check other guests to see if 
it can get
some memory there to satisfy the needs.


Best,
Wei

  parent reply	other threads:[~2017-10-24  1:58 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-20 11:54 [PATCH v1 0/3] Virtio-balloon Improvement Wei Wang
2017-10-20 11:54 ` Wei Wang
2017-10-20 11:54 ` [PATCH v1 1/3] virtio-balloon: replace the coarse-grained balloon_lock Wei Wang
2017-10-20 11:54   ` Wei Wang
2017-10-22  5:20   ` Tetsuo Handa
2017-10-22  5:20   ` Tetsuo Handa
2017-10-22  5:20     ` Tetsuo Handa
2017-10-22 11:24     ` Wei Wang
2017-10-22 11:24     ` Wei Wang
2017-10-22 11:24       ` Wei Wang
2017-10-22 11:50       ` Tetsuo Handa
2017-10-22 11:50         ` Tetsuo Handa
2017-10-24  1:46         ` Wei Wang
2017-10-24  1:46           ` Wei Wang
2017-10-24  1:46         ` Wei Wang
2017-10-22 11:50       ` Tetsuo Handa
2017-10-20 11:54 ` Wei Wang
2017-10-20 11:54 ` [PATCH v1 2/3] virtio-balloon: deflate up to oom_pages on OOM Wei Wang
2017-10-20 11:54 ` Wei Wang
2017-10-20 11:54   ` Wei Wang
2017-10-22  3:21   ` Michael S. Tsirkin
2017-10-22  3:21   ` Michael S. Tsirkin
2017-10-22  3:21     ` Michael S. Tsirkin
2017-10-22  4:11     ` Tetsuo Handa
2017-10-22  4:11     ` Tetsuo Handa
2017-10-22  4:11       ` Tetsuo Handa
2017-10-22 11:31       ` Wei Wang
2017-10-22 11:31         ` Wei Wang
2017-10-22 11:31       ` Wei Wang
2017-10-20 11:54 ` [PATCH v1 3/3] virtio-balloon: stop inflating when OOM occurs Wei Wang
2017-10-20 11:54   ` Wei Wang
2017-10-22 17:13   ` Michael S. Tsirkin
2017-10-22 17:13   ` Michael S. Tsirkin
2017-10-22 17:13     ` Michael S. Tsirkin
2017-10-24  1:58     ` Wei Wang
2017-10-24  1:58       ` Wei Wang
2017-10-24  1:58     ` Wei Wang [this message]
2017-10-20 11:54 ` Wei Wang
2017-10-22  3:19 ` [PATCH v1 0/3] Virtio-balloon Improvement Michael S. Tsirkin
2017-10-22  3:19 ` Michael S. Tsirkin
2017-10-22  3:19   ` Michael S. Tsirkin
2017-10-22 11:19   ` Wei Wang
2017-10-22 11:19     ` Wei Wang
2017-10-22 11:19   ` Wei Wang
2017-11-03  8:35   ` Wei Wang
2017-11-03  8:35     ` Wei Wang
2017-11-03  8:35   ` Wei Wang

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='59EE9E4C.3030207__45861.8061071776$1508810219$gmane$org@intel.com' \
    --to=wei.w.wang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mst@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=virtualization@lists.linux-foundation.org \
    /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.