[PATCH RFC] virtio_balloon: conservative balloon page shrinking

Tetsuo Handa
2020-02-10T03:57:23Z

Wang, Wei W wrote:
> On Saturday, February 8, 2020 8:33 PM, Tetsuo Handa wrote:
> >
> > Is this NUMA aware? Can "node-A's NR_FILE_PAGES is already 0
and
> > node-B's NR_FILE_PAGES is not 0, but allocation request which
triggered this
> > shrinker wants to allocate from only node-B" happen?
>
> No, it's a global counter.
>
> >Can some thread keep
> > this shrinker defunctional by keep increasing NR_FILE_PAGES?
>
> Yes. Actually it's our intention - as long as there are pagecache
pages,
> balloon pages are avoided to be reclaimed.

Then, "node-A's NR_FILE_PAGES is already 0 and node-B's
NR_FILE_PAGES is not 0, but
allocation request which triggered this shrinker wants to allocate from only
node-A"
would be confused by this change, for the pagecache pages for allocating
thread's
interested node are already depleted but the balloon cannot shrink when it
should
because the pagecache pages for allocating thread's uninterested nodes are
not yet
depleted.

>
>
> >
> > Is this patch from "Re: Balloon pressuring page cache"
thread? I hope that
> > the guest could start reclaiming memory based on host's request
(like OOM
> > notifier chain) which is issued when host thinks that host is getting
close to
> > OOM and thus guests should start returning their unused memory to
host.
> > Maybe "periodically (e.g. 5 minutes)" in addition to
"upon close to OOM
> > condition" is also possible.
>
> That's about the host usages. The host side management software decides
when to
> issue a request to balloon (either periodically or event driven), I think
there
> isn't anything we need to do in the balloon driver here.

Well, my comment is rather: "Do not try to reserve guest's memory. In
other words,
do not try to maintain balloons on the guest side. Since host would be able to
cache
file data on the host's cache, guests would be able to quickly fetch file
data from
host's cache via normal I/O requests." ;-)