From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Xen balloon driver improvement (version 1) Date: Thu, 23 Oct 2014 15:29:37 +0100 Message-ID: <1414074577.15687.6.camel@citrix.com> References: <20141022162930.GA8489@zion.uk.xensource.com> <1414065557.1140.7.camel@citrix.com> <20141023121756.GJ9188@zion.uk.xensource.com> <1414067265.15687.4.camel@citrix.com> <20141023130049.GK9188@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141023130049.GK9188@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Stefano Stabellini , Andrew Cooper , xen-devel@lists.xen.org, David Vrabel , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org 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.