Linux Virtualization - Feb 2020 - [PATCH RFC] virtio_balloon: conservative balloon page shrinking

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.

> 
> 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.

Best,
Wei

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." ;-)

On Monday, February 10, 2020 11:57 AM, Tetsuo Handa
wrote:
> 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.
The existing balloon isn't numa aware. "but the balloon cannot shrink
" - even we
let balloon to shrink, it could shrink pages from the uninterested node.

When we have a numa aware balloon, we could further update the shrinker
to check with the per node counter , node_page_state(NR_FILE_PAGES).
> 
> >
> 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." ;-)
Didn't this one. The discussion was about guest pagecache pages v.s. guest
balloon pages.
Why is host's pagecache here?

Best,
Wei