Re: [Xen-devel] Xen balloon driver improvement (version 1)

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Oct 23, 2014 at 12:59:17PM +0100, Ian Campbell wrote:
> On Wed, 2014-10-22 at 17:29 +0100, Wei Liu wrote:
> 
> > For instance, balloon driver can maintain three queues:
> > 
> > 1. queue for 2 MB pages
> > 1. queue for 4 KB pages (delegated to core balloon driver)
> > 1. queue for pages used to mapped pages from other domain
> 
> I think I'd describe this last one as "pages used to provide empty
> address ranges to drivers" or something like that. Yes, they will
> probably be used for mappings, but I don't think that is the only use of
> the alloc_xenballooned_pages interface.
> 

OK. That's more sensible.

> On that subject, how do you handle alloc_xenballooned_pages calls of
> non-2M alignment? Would it be best to do a 2M balloon and queue the rest
> for use on future similar allocations?
> 
> If so then I'm wondering if it might make sense to keep the spare 4K
> pages from doing this on a separate queue to the normal 4K queue, in
> order to keep these sorts pages isolated into 2M regions -- because I
> expect that they cannot be compacted without cooperation with the driver
> which allocated them (which I expect won't even be possible in many
> cases).
> 

Yes, it requires cooperation from the driver, and I don't think it's a
good idea because that would mean drivers need to do weird things which
hinder performance and increase complexity. 

I intend to not touch them, just leave them in separate queue.

> > These flowcharts assume normal page size is 4K and huge page size is
> > 2M.  They show how two queues are maintained.
> > 
> > ![Increase Reservation](increase-reservation.png)
> 
> There's a few implicit "requeue on failure" arcs missing on some of
> these, I think adding them would make the picture hard to follow, but
> perhaps a footnote?
>  

Correct. I omitted "requeue on failure". I will add a footnote.

> On both here and decrease there are attempts to allocate (from either
> the queue or the kernel, depending) 2M which could fail. I wonder if it
> is worth inserting "kick THP and give it a chance"? It's a question of
> tradeoffs in the latency of a ballooning operation vs the efficiency
> with which we can use 2M allocations.
> 

No, THP is not involved. I think you mean balloon page compaction.

I'm not sure if it's a good idea because we're now introducing latency
that we can't control. At the very least, if guest admin really cares he
/ she should be able to kick off compaction voluntarily.

Wei.

> > ![Decrease Reservation](decrease-reservation.png)
> > 
> > ![Exchange Pages](exchange-pages.png)
> > 
> 
> 

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