[Xen-devel] [PATCH v2] x86/mm: pod: Use the correct memory flags for alloc_domheap_page{, s}
The last parameter of alloc_domheap_page{s,} contain the memory flags and not the order of the allocation. Use 0 for the call in p2m_pod_set_cache_target as it was before 1069d63c5ef2510d08b83b2171af660e5bb18c63 "x86/mm/p2m: use defines for page sizes". Note that PAGE_ORDER_4K is also equal to 0 so the behavior stays the same. For the call in p2m_pod_offline_or_broken_replace we want to allocate the new page on the same numa node as the previous page. So retrieve the numa node and pass it in the memory flags. Signed-off-by: Julien Grall --- Note that the patch has only been build tested. Cc: George Dunlap Cc: Keir Fraser Cc: Jan Beulich Cc: Andrew Cooper Cc: Dario Faggioli Changes in v2: - Change the behavior of p2m_pod_offline_or_broken_replace to allocate the new page on the same numa node as the previous page. --- xen/arch/x86/mm/p2m-pod.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c index 901da37..acd85ea 100644 --- a/xen/arch/x86/mm/p2m-pod.c +++ b/xen/arch/x86/mm/p2m-pod.c @@ -222,7 +222,7 @@ p2m_pod_set_cache_target(struct p2m_domain *p2m, unsigned long pod_target, int p else order = PAGE_ORDER_4K; retry: -page = alloc_domheap_pages(d, order, PAGE_ORDER_4K); +page = alloc_domheap_pages(d, order, 0); if ( unlikely(page == NULL) ) { if ( order == PAGE_ORDER_2M ) @@ -471,13 +471,14 @@ p2m_pod_offline_or_broken_replace(struct page_info *p) { struct domain *d; struct p2m_domain *p2m; +nodeid_t node = phys_to_nid(page_to_maddr(p)); if ( !(d = page_get_owner(p)) || !(p2m = p2m_get_hostp2m(d)) ) return; free_domheap_page(p); -p = alloc_domheap_page(d, PAGE_ORDER_4K); +p = alloc_domheap_page(d, MEMF_node(node)); if ( unlikely(!p) ) return; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/mm: pod: Use the correct memory flags for alloc_domheap_page{, s}
On Fri, 2015-10-23 at 11:33 +0100, Julien Grall wrote: > The last parameter of alloc_domheap_page{s,} contain the memory flags > and > not the order of the allocation. > > Use 0 for the call in p2m_pod_set_cache_target as it was before > 1069d63c5ef2510d08b83b2171af660e5bb18c63 "x86/mm/p2m: use defines for > page sizes". Note that PAGE_ORDER_4K is also equal to 0 so the > behavior > stays the same. > > For the call in p2m_pod_offline_or_broken_replace we want to allocate > the new page on the same numa node as the previous page. So retrieve > the > numa node and pass it in the memory flags. > > Signed-off-by: Julien Grall > > --- > > Note that the patch has only been build tested. > I've done some basic testing. That means I: - created an HVM guest with memory < maxmem - played with `xl mem-set' and `xl mem-max' on it - local migrated it - played with `xl mem-set' and `xl mem-max' on it again - shutdown it All done on a NUMA host, with memory dancing (during the 'play' phases) up and down the amount of RAM present in each NUMA node. I'm not sure how I should trigger and test memory hotunplug, neither whether or not my testbox supports it. Since it seems that memory hotumplug is what was really necessary, I'm not sure it's appropriate to add the following tag: Tested-by: Dario Faggioli but I'll let you guys (Jan, mainly, I guess) decide. If the above is deemed enough, feel free to stick it there, if not, fine anyway. :-) Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/mm: pod: Use the correct memory flags for alloc_domheap_page{, s}
On 23/10/15 11:33, Julien Grall wrote: > The last parameter of alloc_domheap_page{s,} contain the memory flags and > not the order of the allocation. > > Use 0 for the call in p2m_pod_set_cache_target as it was before > 1069d63c5ef2510d08b83b2171af660e5bb18c63 "x86/mm/p2m: use defines for > page sizes". Note that PAGE_ORDER_4K is also equal to 0 so the behavior > stays the same. > > For the call in p2m_pod_offline_or_broken_replace we want to allocate > the new page on the same numa node as the previous page. So retrieve the > numa node and pass it in the memory flags. > > Signed-off-by: Julien Grall Acked-by: George Dunlap > > --- > > Note that the patch has only been build tested. It would be nice if we could properly test the codepath in question before checking it in, but we have lots of time before the release for people to find this sort of thing. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/mm: pod: Use the correct memory flags for alloc_domheap_page{, s}
>>> On 26.10.15 at 11:29, wrote: > On 23/10/15 11:33, Julien Grall wrote: >> Note that the patch has only been build tested. > > It would be nice if we could properly test the codepath in question > before checking it in, but we have lots of time before the release for > people to find this sort of thing. To be honest, I'd rather put it in right away. There's no strict need to backport it, and in case there is a problem we can always fix/revert in -unstable. Most of the changes to memory hot (un)plug paths go in that way, due to the rareness of systems to test such on. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/mm: pod: Use the correct memory flags for alloc_domheap_page{, s}
On 26/10/15 10:40, Jan Beulich wrote: On 26.10.15 at 11:29, wrote: >> On 23/10/15 11:33, Julien Grall wrote: >>> Note that the patch has only been build tested. >> >> It would be nice if we could properly test the codepath in question >> before checking it in, but we have lots of time before the release for >> people to find this sort of thing. > > To be honest, I'd rather put it in right away. There's no strict need > to backport it, and in case there is a problem we can always fix/revert > in -unstable. Most of the changes to memory hot (un)plug paths go > in that way, due to the rareness of systems to test such on. Indeed, that's what I meant -- we should check it in right away, to maximize the possibility that if there is a bug, it will be caught in all the testing (both ad-hoc and explicit) that will happen between now and the next release. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel