[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: non-contiguous allocations

>>> 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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.