Re: Re: non-contiguous allocations

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

>>> On 06.05.11 at 20:46, Keir Fraser <keir.xen@gmail.com> wrote:
> On 06/05/2011 19:12, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
>> 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()?
> 
> Yes it should just work. Are you sure you actually have more than 128MB
> available (not all allocated to dom0 for example)?
> 
> 
>>  From which pool should the per-cpu tracebuffers
>> get allocated?  alloc_domheap_page() wants a domain, so I think thats
>> the wrong interface.
> 
> Yes, sticking with alloc_xenheap_pages() is good.

It really depends on whether you expect to get memory that has
(even on 32-bit) a virtual mapping, or you want to map it at an
arbitrary virtual address after wards. alloc_xenheap_pages() gives
you mapped memory (and the amount you can get is rather limited
on 32-bit), while alloc_domheap_pages(NULL, ...) gives you
memory that has a mapping only on 64-bit (and, once we'll find it
necessary to support machines with more than 5Tb, even that
may not hold anymore) but it equally not associated with any
domain.

Jan