Re: [Xen-devel] Linux Xen Balloon Driver Improvement (Draft 2)

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Oct 28, 2014 at 10:51:34AM +0000, David Vrabel wrote:
[...]
> >>
> > 
> > What would make this design different when Xen knows how to defragment
> > frames?
> > 
> > We end up ballooning out a 2M host frame if the underlying huge frame is
> > defragemented (instead of a bunch of 4K frames). We're giving huge frame
> > back to Xen, so it's OK; then we exchange in 512 4K consecutive pages
> > (or a 2M page if we merge them) with 2M frame backing them. Xen is not
> > harmed; guest now has got a huge frame. It's only making things better
> > if Xen knows how to defragemnt.
> 
> Um.  Yes, of course if you use a contiguous and aligned set of of 4K
> ballooned pages then it it will work well -- this is exactly the point I
> am making. But this is not what your design says.
> 

Well, I've said I will prototype different approaches to see which one
works better in practice (with maintenance burden taken into account).

What these drafts say is by no means final, because to me memory
subsystem optimisation is very empirical.

> Also, to quote you from the thread on draft 1:
> 
> "As for moving contiguous ballooned pages from 4K list to 2M list,
> unfortunately I see a problem with this proposal: The 4K pages list is
> not sorted. Sorting it requires hooking into core balloon driver -- that
> is, to grab multiple locks to avoid racing with page migration thread,
> which is prone to error."
> 
> Although I don't understand the comments about multiple locks etc. since
> I think the core balloon driver should be responsible for maintaining
> the order of the list.
> 

"Prone to error" is a bit overrated, I admit.

Core balloon driver doesn't sort pages at the moment. To sort pages we
either 1) sort them in core driver, 2) dequeue as many as possible to
Xen balloon driver then sort.

#1 is less desirable because upstream is not likely to accept this
change. Core balloon driver is basically a vault to keep those pages.
And I was thinking to have Xen balloon driver worker to hook into core
balloon driver when I replied. In that case I need to carefully fiddle
with some page locks to keep pages safe from page migration thread which
is tricky.

#2 Dequeueing a balloon page may fail due to contention with compaction.
When under memory pressure we might not able to dequeue all pages to
effectively coalesce them. However this approach is still worth trying
to see how it works.

Wei.

> David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel