* Difference between alloc_domheap_pages vs. alloc_xenheap_pages?
@ 2013-06-26 22:41 Xinxin Jin
2013-06-27 8:11 ` Ian Campbell
0 siblings, 1 reply; 3+ messages in thread
From: Xinxin Jin @ 2013-06-26 22:41 UTC (permalink / raw)
To: Xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 202 bytes --]
Hi,
I noticed the only difference between the two is to add PGC_xen_heap flag
in allocated xenheap pages. So does it matter to exchange these two
functions when allocating a heap page?
Thanks,
Xinxin
[-- Attachment #1.2: Type: text/html, Size: 568 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Difference between alloc_domheap_pages vs. alloc_xenheap_pages?
2013-06-26 22:41 Difference between alloc_domheap_pages vs. alloc_xenheap_pages? Xinxin Jin
@ 2013-06-27 8:11 ` Ian Campbell
2013-06-27 8:19 ` Keir Fraser
0 siblings, 1 reply; 3+ messages in thread
From: Ian Campbell @ 2013-06-27 8:11 UTC (permalink / raw)
To: Xinxin Jin; +Cc: Xen-devel
On Wed, 2013-06-26 at 15:41 -0700, Xinxin Jin wrote:
> I noticed the only difference between the two is to add PGC_xen_heap
> flag in allocated xenheap pages. So does it matter to exchange these
> two functions when allocating a heap page?
xenheap pages are always mapped, domheap pages are only mapped on demand
with (un)map_domain_page. The big clue is that alloc_xenheap_pages
returns a void* while alloc_domheap_pages returns a struct page_info*.
On some architectures with a large virtual address space (i.e. 64-bit
ones) the two can be combined and the distinction becomes a bit moot,
but it remains for the benefit of common code and also because even on
64-bit architectures when you have large amounts of RAM you may still
end up with RAM which is not permanently mapped -- e.g. on x86_64 if you
have >5TB of RAM then you end up with a split again.
Ian.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Difference between alloc_domheap_pages vs. alloc_xenheap_pages?
2013-06-27 8:11 ` Ian Campbell
@ 2013-06-27 8:19 ` Keir Fraser
0 siblings, 0 replies; 3+ messages in thread
From: Keir Fraser @ 2013-06-27 8:19 UTC (permalink / raw)
To: Ian Campbell, Xinxin Jin; +Cc: Xen-devel
On 27/06/2013 09:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-06-26 at 15:41 -0700, Xinxin Jin wrote:
>
>
>> I noticed the only difference between the two is to add PGC_xen_heap
>> flag in allocated xenheap pages. So does it matter to exchange these
>> two functions when allocating a heap page?
>
> xenheap pages are always mapped, domheap pages are only mapped on demand
> with (un)map_domain_page. The big clue is that alloc_xenheap_pages
> returns a void* while alloc_domheap_pages returns a struct page_info*.
>
> On some architectures with a large virtual address space (i.e. 64-bit
> ones) the two can be combined and the distinction becomes a bit moot,
> but it remains for the benefit of common code and also because even on
> 64-bit architectures when you have large amounts of RAM you may still
> end up with RAM which is not permanently mapped -- e.g. on x86_64 if you
> have >5TB of RAM then you end up with a split again.
Also xenheap-allocated pages must be explicitly freed by Xen, usually during
domain destruction.
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-06-27 8:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-26 22:41 Difference between alloc_domheap_pages vs. alloc_xenheap_pages? Xinxin Jin
2013-06-27 8:11 ` Ian Campbell
2013-06-27 8:19 ` Keir Fraser
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).