On 29/09/15 13:57, Jan Beulich wrote: >>>> On 29.09.15 at 14:20, <andrew.coop...@citrix.com> wrote: >> On 28/09/15 15:30, Jan Beulich wrote: >>> --- a/xen/arch/x86/mm/p2m-pod.c >>> +++ b/xen/arch/x86/mm/p2m-pod.c >>> @@ -119,20 +119,23 @@ p2m_pod_cache_add(struct p2m_domain *p2m >>> >>> unlock_page_alloc(p2m); >>> >>> - /* Then add the first one to the appropriate populate-on-demand list */ >>> - switch(order) >>> + /* Then add to the appropriate populate-on-demand list. */ >>> + switch ( order ) >>> { >>> + case PAGE_ORDER_1G: >>> + for ( i = 0; i < (1UL << PAGE_ORDER_1G); i += 1UL << PAGE_ORDER_2M >>> ) >>> + page_list_add_tail(page + i, &p2m->pod.super); >>> + break; >>> case PAGE_ORDER_2M: >>> - page_list_add_tail(page, &p2m->pod.super); /* lock: page_alloc */ >>> - p2m->pod.count += 1 << order; >>> + page_list_add_tail(page, &p2m->pod.super); >>> break; >>> case PAGE_ORDER_4K: >>> - page_list_add_tail(page, &p2m->pod.single); /* lock: page_alloc */ >>> - p2m->pod.count += 1; >>> + page_list_add_tail(page, &p2m->pod.single); >>> break; >>> default: >>> BUG(); >>> } >>> + p2m->pod.count += 1 << order; >> 1UL > Not really - the field is a "long" one, so at best 1L or 1U. And then > all the valid order values are visible right above, for none of them > it makes a difference, and there are ample similar uses scattered > around the file (yes, bad examples are no excuse, but in cases > where the suffix doesn't really matter I think it is better to omit it). > >> Otherwise, Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> > Let me know regrading this one,
For sanity sake, I would suggest going with 1L as one less place to go wrong when we gain 512GB superpages. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel