>>> On 06.05.11 at 20:46, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 06/05/2011 19:12, "Olaf Hering" <olaf@xxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home