All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Nadav Amit <namit@vmware.com>,
	Alexander Duyck <alexander.h.duyck@linux.intel.com>,
	Tyler Sanderson <tysand@google.com>,
	"Wang, Wei W" <wei.w.wang@intel.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Michal Hocko <mhocko@kernel.org>,
	virtio-dev@lists.oasis-open.org
Subject: Re: Balloon pressuring page cache
Date: Wed, 5 Feb 2020 09:31:47 +0100	[thread overview]
Message-ID: <6ed307d1-cad1-c6d7-d4dd-2a1f0bd9fcb8@redhat.com> (raw)
In-Reply-To: <20200204135817-mutt-send-email-mst@kernel.org>

On 04.02.20 21:33, Michael S. Tsirkin wrote:
> On Tue, Feb 04, 2020 at 05:56:22PM +0100, David Hildenbrand wrote:
>> [...]
>>
>>>>
>>>> Issue 2: When called via the shrinker, (but also to fix Issue 1), it could be
>>>> that we do have VIRTIO_BALLOON_F_MUST_TELL_HOST. I assume this means
>>>> (-ENOCLUE) that we have to wait until the hypervisor notifies us via the STOP? Or
>>>> for which event do we have to wait? Because there is no way to *tell host* here
>>>> that we want to reuse a page. The hypervisor will *tell us* when we can reuse pages.
>>>> For the shrinker it is simple: Don't use the shrinker with
>>>> VIRTIO_BALLOON_F_MUST_TELL_HOST :) . But to fix Issue 1, we *would* have to wait
>>>> until we get a STOP signal. That is not really possible because it might
>>>> take an infinite amount of time.
>>>>
>>>> Michael, any clue on which event we have to wait with
>>>> VIRTIO_BALLOON_F_MUST_TELL_HOST? IMHO, I don't think
>>>> VIRTIO_BALLOON_F_MUST_TELL_HOST applies to VIRTIO_BALLOON_F_FREE_PAGE_HINT and
>>>> we'd better document that. It introduces complexity with no clear benefit.
>>>
>>> I meant that we must wait for host to see the hint. Signalled via using
>>> the buffer.  But maybe that's too far in the meaning from
>>> VIRTIO_BALLOON_F_MUST_TELL_HOST and we need a separate new flag for
>>
>> Yes, that's what I think.
>>
>>> that. Then current code won't be broken (yay!) but we need to
>>> document another flag that's pretty similar.
>>
>> I mean, do we need a flag at all as long as there is no user?
>> Introducing a flag and documenting it if nobody uses it does not sound
>> like a work I will enjoy :)
> 
> It's not the user. It's the non-orthogonality that I find inelegant.
> 
> Let me try to formulate the issue, forgive me for thinking aloud
> (and I Cc'd virtio-dev since we are talking spec things here):
> 
> The annoying thing is that with Alex's VIRTIO_BALLOON_F_REPORTING
> host does depend on guest not touching memory before host uses it.
> So functionally VIRTIO_BALLOON_F_FREE_PAGE_HINT and
> VIRTIO_BALLOON_F_REPORTING really are supposed to do
> exectly the same thing, with the differences being
> - VIRTIO_BALLOON_F_FREE_PAGE_HINT comes upon host's request.
>   VIRTIO_BALLOON_F_REPORTING is initiated by guest.
> - VIRTIO_BALLOON_F_FREE_PAGE_HINT does not always wait for
>   host to use the hint before touching the page.
>   Well it almost always does, but there's an exception in the
>   shrinker which tries to stop reporting as quickly as possible
>   in the case of a slow host.
>   VIRTIO_BALLOON_F_REPORTING always does.
>   This means host can blow the page away when it sees the hint.
> 
> Now the point is that with VIRTIO_BALLOON_F_REPORTING
> I think you really must wait for host to use the hint.
> But with VIRTIO_BALLOON_F_FREE_PAGE_HINT it depends
> on how host uses it. Something to think about,
> I'm not sure what is the best thing to do here.


I think VIRTIO_BALLOON_F_FREE_PAGE_HINT is really the special case and
shall be left alone (not messed with VIRTIO_BALLOON_F_MUST_TELL_HOST).
Initiated by the host, complicated protocol and semantics, guest can
reuse pages any time it wants ("hint").

VIRTIO_BALLOON_F_REPORTING is *basically* ordinary inflation on
stereoids (be able to report a size for each page and multiple pages in
one go) BUT, we can currently *never* have
VIRTIO_BALLOON_F_MUST_TELL_HOST semantics - there is no deflation.

We could rename VIRTIO_BALLOON_F_REPORTING to something like
VIRTIO_BALLOON_F_SIZE and make it obey to
VIRTIO_BALLOON_F_MUST_TELL_HOST (meaning, there would have to be a
deflate queue as well!) - but it contradicts to the real needs.
VIRTIO_BALLOON_F_REPORTING comnbined with
VIRTIO_BALLOON_F_MUST_TELL_HOST would not be usable by Linux for free
page reporting.

Well, as QEMU never sets VIRTIO_BALLOON_F_MUST_TELL_HOST we would be
fine. Alexander would have to add an inflate+deflate queue and make his
feature depend on !VIRTIO_BALLOON_F_MUST_TELL_HOST.

Is that the consistency you're looking for? Alexander, thoughts?

-- 
Thanks,

David / dhildenb



WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Nadav Amit <namit@vmware.com>,
	Alexander Duyck <alexander.h.duyck@linux.intel.com>,
	Tyler Sanderson <tysand@google.com>,
	"Wang, Wei W" <wei.w.wang@intel.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Michal Hocko <mhocko@kernel.org>,
	virtio-dev@lists.oasis-open.org
Subject: [virtio-dev] Re: Balloon pressuring page cache
Date: Wed, 5 Feb 2020 09:31:47 +0100	[thread overview]
Message-ID: <6ed307d1-cad1-c6d7-d4dd-2a1f0bd9fcb8@redhat.com> (raw)
In-Reply-To: <20200204135817-mutt-send-email-mst@kernel.org>

On 04.02.20 21:33, Michael S. Tsirkin wrote:
> On Tue, Feb 04, 2020 at 05:56:22PM +0100, David Hildenbrand wrote:
>> [...]
>>
>>>>
>>>> Issue 2: When called via the shrinker, (but also to fix Issue 1), it could be
>>>> that we do have VIRTIO_BALLOON_F_MUST_TELL_HOST. I assume this means
>>>> (-ENOCLUE) that we have to wait until the hypervisor notifies us via the STOP? Or
>>>> for which event do we have to wait? Because there is no way to *tell host* here
>>>> that we want to reuse a page. The hypervisor will *tell us* when we can reuse pages.
>>>> For the shrinker it is simple: Don't use the shrinker with
>>>> VIRTIO_BALLOON_F_MUST_TELL_HOST :) . But to fix Issue 1, we *would* have to wait
>>>> until we get a STOP signal. That is not really possible because it might
>>>> take an infinite amount of time.
>>>>
>>>> Michael, any clue on which event we have to wait with
>>>> VIRTIO_BALLOON_F_MUST_TELL_HOST? IMHO, I don't think
>>>> VIRTIO_BALLOON_F_MUST_TELL_HOST applies to VIRTIO_BALLOON_F_FREE_PAGE_HINT and
>>>> we'd better document that. It introduces complexity with no clear benefit.
>>>
>>> I meant that we must wait for host to see the hint. Signalled via using
>>> the buffer.  But maybe that's too far in the meaning from
>>> VIRTIO_BALLOON_F_MUST_TELL_HOST and we need a separate new flag for
>>
>> Yes, that's what I think.
>>
>>> that. Then current code won't be broken (yay!) but we need to
>>> document another flag that's pretty similar.
>>
>> I mean, do we need a flag at all as long as there is no user?
>> Introducing a flag and documenting it if nobody uses it does not sound
>> like a work I will enjoy :)
> 
> It's not the user. It's the non-orthogonality that I find inelegant.
> 
> Let me try to formulate the issue, forgive me for thinking aloud
> (and I Cc'd virtio-dev since we are talking spec things here):
> 
> The annoying thing is that with Alex's VIRTIO_BALLOON_F_REPORTING
> host does depend on guest not touching memory before host uses it.
> So functionally VIRTIO_BALLOON_F_FREE_PAGE_HINT and
> VIRTIO_BALLOON_F_REPORTING really are supposed to do
> exectly the same thing, with the differences being
> - VIRTIO_BALLOON_F_FREE_PAGE_HINT comes upon host's request.
>   VIRTIO_BALLOON_F_REPORTING is initiated by guest.
> - VIRTIO_BALLOON_F_FREE_PAGE_HINT does not always wait for
>   host to use the hint before touching the page.
>   Well it almost always does, but there's an exception in the
>   shrinker which tries to stop reporting as quickly as possible
>   in the case of a slow host.
>   VIRTIO_BALLOON_F_REPORTING always does.
>   This means host can blow the page away when it sees the hint.
> 
> Now the point is that with VIRTIO_BALLOON_F_REPORTING
> I think you really must wait for host to use the hint.
> But with VIRTIO_BALLOON_F_FREE_PAGE_HINT it depends
> on how host uses it. Something to think about,
> I'm not sure what is the best thing to do here.


I think VIRTIO_BALLOON_F_FREE_PAGE_HINT is really the special case and
shall be left alone (not messed with VIRTIO_BALLOON_F_MUST_TELL_HOST).
Initiated by the host, complicated protocol and semantics, guest can
reuse pages any time it wants ("hint").

VIRTIO_BALLOON_F_REPORTING is *basically* ordinary inflation on
stereoids (be able to report a size for each page and multiple pages in
one go) BUT, we can currently *never* have
VIRTIO_BALLOON_F_MUST_TELL_HOST semantics - there is no deflation.

We could rename VIRTIO_BALLOON_F_REPORTING to something like
VIRTIO_BALLOON_F_SIZE and make it obey to
VIRTIO_BALLOON_F_MUST_TELL_HOST (meaning, there would have to be a
deflate queue as well!) - but it contradicts to the real needs.
VIRTIO_BALLOON_F_REPORTING comnbined with
VIRTIO_BALLOON_F_MUST_TELL_HOST would not be usable by Linux for free
page reporting.

Well, as QEMU never sets VIRTIO_BALLOON_F_MUST_TELL_HOST we would be
fine. Alexander would have to add an inflate+deflate queue and make his
feature depend on !VIRTIO_BALLOON_F_MUST_TELL_HOST.

Is that the consistency you're looking for? Alexander, thoughts?

-- 
Thanks,

David / dhildenb


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2020-02-05  8:32 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29  0:22 Balloon pressuring page cache Tyler Sanderson via Virtualization
2020-01-29 10:31 ` David Hildenbrand
2020-01-29 19:11   ` Tyler Sanderson via Virtualization
2020-01-30 15:02     ` David Hildenbrand
2020-01-30 15:02       ` David Hildenbrand
2020-01-30 15:20       ` Michael S. Tsirkin
2020-01-30 15:20         ` Michael S. Tsirkin
2020-01-30 15:23         ` David Hildenbrand
2020-01-30 15:23           ` David Hildenbrand
2020-01-30 15:31       ` Wang, Wei W
2020-01-30 15:31         ` Wang, Wei W
2020-01-30 19:59         ` Tyler Sanderson
2020-01-30 19:59           ` Tyler Sanderson via Virtualization
2020-02-03 13:11           ` Michael S. Tsirkin
2020-02-03 13:11             ` Michael S. Tsirkin
2020-02-03 16:18             ` Alexander Duyck
2020-02-03 16:34               ` David Hildenbrand
2020-02-03 16:34                 ` David Hildenbrand
2020-02-03 17:03                 ` Michael S. Tsirkin
2020-02-03 17:03                   ` Michael S. Tsirkin
2020-02-03 20:32                   ` Tyler Sanderson
2020-02-03 20:32                     ` Tyler Sanderson via Virtualization
2020-02-03 21:22                     ` Alexander Duyck
2020-02-03 23:16                       ` Tyler Sanderson
2020-02-03 23:16                         ` Tyler Sanderson via Virtualization
2020-02-04  0:10                         ` Alexander Duyck
2020-02-04  5:45                     ` Michael S. Tsirkin
2020-02-04  5:45                       ` Michael S. Tsirkin
2020-02-04  8:29                     ` David Hildenbrand
2020-02-04  8:29                       ` David Hildenbrand
2020-02-04 18:52                       ` Tyler Sanderson
2020-02-04 18:52                         ` Tyler Sanderson via Virtualization
2020-02-04 18:56                         ` Michael S. Tsirkin
2020-02-04 18:56                           ` Michael S. Tsirkin
2020-02-04 19:17                         ` David Hildenbrand
2020-02-04 19:17                           ` David Hildenbrand
2020-02-04 23:58                           ` Tyler Sanderson
2020-02-04 23:58                             ` Tyler Sanderson via Virtualization
2020-02-05  0:15                             ` Tyler Sanderson
2020-02-05  0:15                               ` Tyler Sanderson via Virtualization
2020-02-05  6:57                             ` Michael S. Tsirkin
2020-02-05  6:57                               ` Michael S. Tsirkin
2020-02-05 19:01                               ` Tyler Sanderson
2020-02-05 19:01                                 ` Tyler Sanderson via Virtualization
2020-02-05 19:22                                 ` Alexander Duyck
2020-02-05 21:44                                   ` Tyler Sanderson
2020-02-05 21:44                                     ` Tyler Sanderson via Virtualization
2020-02-06 11:00                                     ` David Hildenbrand
2020-02-06 11:00                                       ` David Hildenbrand
2020-02-03 22:50                 ` Nadav Amit
2020-02-03 22:50                   ` Nadav Amit via Virtualization
2020-02-04  8:35                   ` David Hildenbrand
2020-02-04  8:35                     ` David Hildenbrand
2020-02-04  8:40                     ` Michael S. Tsirkin
2020-02-04  8:40                       ` Michael S. Tsirkin
2020-02-04  8:48                       ` David Hildenbrand
2020-02-04  8:48                         ` David Hildenbrand
2020-02-04 14:30                       ` David Hildenbrand
2020-02-04 14:30                         ` David Hildenbrand
2020-02-04 16:50                         ` Michael S. Tsirkin
2020-02-04 16:50                           ` Michael S. Tsirkin
2020-02-04 16:56                           ` David Hildenbrand
2020-02-04 16:56                             ` David Hildenbrand
2020-02-04 20:33                             ` Michael S. Tsirkin
2020-02-04 20:33                               ` [virtio-dev] " Michael S. Tsirkin
2020-02-04 20:33                               ` Michael S. Tsirkin
2020-02-05  8:31                               ` David Hildenbrand [this message]
2020-02-05  8:31                                 ` [virtio-dev] " David Hildenbrand
2020-02-05  6:52                           ` Wang, Wei W
2020-02-05  6:52                             ` Wang, Wei W
2020-02-05  7:05                             ` Michael S. Tsirkin
2020-02-05  7:05                               ` Michael S. Tsirkin
2020-02-05  8:50                               ` Wang, Wei W
2020-02-05  8:50                                 ` Wang, Wei W
2020-02-05  6:49                         ` Wang, Wei W
2020-02-05  6:49                           ` Wang, Wei W
2020-02-05  8:19                           ` David Hildenbrand
2020-02-05  8:19                             ` David Hildenbrand
2020-02-05  8:54                             ` Wang, Wei W
2020-02-05  8:54                               ` Wang, Wei W
2020-02-05  8:56                               ` David Hildenbrand
2020-02-05  8:56                                 ` David Hildenbrand
2020-02-05  9:00                                 ` Wang, Wei W
2020-02-05  9:00                                   ` Wang, Wei W
2020-02-05  9:05                                   ` David Hildenbrand
2020-02-05  9:05                                     ` David Hildenbrand
2020-02-05  9:19                                     ` Wang, Wei W
2020-02-05  9:19                                       ` Wang, Wei W
2020-02-05  9:22                                       ` David Hildenbrand
2020-02-05  9:22                                         ` David Hildenbrand
2020-02-05  9:35                                         ` Wang, Wei W
2020-02-05  9:35                                           ` Wang, Wei W
2020-02-05  9:37                                           ` David Hildenbrand
2020-02-05  9:37                                             ` David Hildenbrand
2020-02-05  9:49                                             ` Wang, Wei W
2020-02-05  9:49                                               ` Wang, Wei W
2020-02-05  9:58                                               ` David Hildenbrand
2020-02-05  9:58                                                 ` David Hildenbrand
2020-02-05 10:25                                                 ` Michael S. Tsirkin
2020-02-05 10:25                                                   ` Michael S. Tsirkin
2020-02-05 10:42                                                   ` David Hildenbrand
2020-02-05 10:42                                                     ` David Hildenbrand
2020-02-05  9:35                                         ` Michael S. Tsirkin
2020-02-05  9:35                                           ` Michael S. Tsirkin
2020-02-05 18:43                                   ` Tyler Sanderson
2020-02-05 18:43                                     ` Tyler Sanderson via Virtualization
2020-02-06  9:30                                     ` Wang, Wei W
2020-02-06  9:30                                       ` Wang, Wei W
2020-02-05  7:35                   ` Nadav Amit
2020-02-05  7:35                     ` Nadav Amit via Virtualization
2020-02-05  8:19                     ` David Hildenbrand
2020-02-05  8:19                       ` David Hildenbrand
2020-02-05 10:27                       ` Michael S. Tsirkin
2020-02-05 10:27                         ` Michael S. Tsirkin
2020-02-05 10:43                         ` David Hildenbrand
2020-02-05 10:43                           ` David Hildenbrand
2020-01-30 22:46       ` Tyler Sanderson
2020-01-30 22:46         ` Tyler Sanderson via Virtualization
2020-02-02  0:21     ` David Rientjes via Virtualization

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=6ed307d1-cad1-c6d7-d4dd-2a1f0bd9fcb8@redhat.com \
    --to=david@redhat.com \
    --cc=alexander.h.duyck@linux.intel.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mst@redhat.com \
    --cc=namit@vmware.com \
    --cc=rientjes@google.com \
    --cc=tysand@google.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wei.w.wang@intel.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.