Re: non-contiguous allocations

["Jan Beulich" <JBeulich@novell.com>]

>>> On 18.04.11 at 20:45, Olaf Hering <olaf@aepfle.de> 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.
> 
> how do I allocate a few mfns and give them a virtual address?
> I dont find a malloc like interface to allocate random pages.

alloc_domheap_pages() followed by map_pages_to_xen() would be
one way, if you pre-reserve virtual address space (suitable hence
only for 64-bit and only if you can set a reasonable upper bound on
the amount to want to map).

Otherwise I think the only option is to introduce indirection (using
the 1:1 mapping, and setting up an array of pointers). That may
however be a little difficult if (and I think that's the case) data
chunks aren't always of the same size (as then you need to deal
with the roll-over into the next page).

Jan