From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: non-contiguous allocations Date: Fri, 6 May 2011 20:12:34 +0200 Message-ID: <20110506181234.GA24767@aepfle.de> References: <3e95e737bc51c2295926.1301508274@localhost> <1301656691.9447.88.camel@elijah> <20110418184541.GA16935@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <20110418184541.GA16935@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Mon, Apr 18, Olaf Hering wrote: > On Fri, Apr 01, George Dunlap wrote: > > > On Wed, 2011-03-30 at 19:04 +0100, Olaf Hering wrote: > > > Using the u16 means each cpu could in theory use up to 256MB as trace > > > buffer. However such a large allocation will currently fail on x86 due > > > to the MAX_ORDER limit. > > > > FWIW, I don't believe that there's any reason the allocations have to be > > contiguous any more. I kept them contiguous to minimize the changes to > > the moving parts near a release. But the new system has been pretty > > well tested now, so I think looking at non-contiguous allocations may be > > worthwhile. Is there a way to allocate more than 128mb with repeated calls to alloc_xenheap_page()? From which pool should the per-cpu tracebuffers get allocated? alloc_domheap_page() wants a domain, so I think thats the wrong interface. Olaf