[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, 2014-10-23 at 14:00 +0100, Wei Liu wrote:
> On Thu, Oct 23, 2014 at 01:27:45PM +0100, Ian Campbell wrote:
> > On Thu, 2014-10-23 at 13:17 +0100, Wei Liu wrote:
> > > On Thu, Oct 23, 2014 at 12:59:17PM +0100, Ian Campbell wrote:
> > > > 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 have a feeling it may even be impossible in some cases.
> > 
> > > I intend to not touch them, just leave them in separate queue.
> > 
> > i.e. a separate one from the "unusued ballooned 4k"?
> > 
> 
> Yes. A separate one -- if the "unused ballooned 4k" queue refers to the
> queue that holds balloon pages which are subject to balloon page
> compaction.

Correct.

> OK, I think there's some misunderstanding here. When kernel tries to
> allocate high order page, it already kicks of compaction (including
> normal page and balloon page compaction) when fast path fails.

Aha, that was what I missed, thanks!

> So I was thinking about something like calling compact_zone or rolling
> our own implementation when I saw your reply. That's a very time
> consuming operation and time varies depending on kernel parameters and
> the status of memory fragmentation.

Right, that doesn't sound desirable.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.