|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 05/12] xen: introduce reserve_heap_pages
On 15.04.2020 03:02, Stefano Stabellini wrote:
> Introduce a function named reserve_heap_pages (similar to
> alloc_heap_pages) that allocates a requested memory range. Call
> __alloc_heap_pages for the implementation.
>
> Change __alloc_heap_pages so that the original page doesn't get
> modified, giving back unneeded memory top to bottom rather than bottom
> to top.
While it may be less of a problem within a zone, doing so is
against our general "return high pages first" policy.
> @@ -1073,7 +1073,42 @@ static struct page_info *alloc_heap_pages(
> return NULL;
> }
>
> - __alloc_heap_pages(&pg, order, memflags, d);
> + __alloc_heap_pages(pg, order, memflags, d);
> + return pg;
> +}
> +
> +static struct page_info *reserve_heap_pages(struct domain *d,
> + paddr_t start,
> + unsigned int order,
> + unsigned int memflags)
> +{
> + nodeid_t node;
> + unsigned int zone;
> + struct page_info *pg;
> +
> + if ( unlikely(order > MAX_ORDER) )
> + return NULL;
> +
> + spin_lock(&heap_lock);
> +
> + /*
> + * Claimed memory is considered unavailable unless the request
> + * is made by a domain with sufficient unclaimed pages.
> + */
> + if ( (outstanding_claims + (1UL << order) > total_avail_pages) &&
> + ((memflags & MEMF_no_refcount) ||
> + !d || d->outstanding_pages < (1UL << order)) )
> + {
> + spin_unlock(&heap_lock);
> + return NULL;
> + }
Where would such a claim come from? Given the purpose I'd assume
the function (as well as reserve_domheap_pages()) can actually be
__init. With that I'd then also be okay with them getting built
unconditionally, i.e. even on x86.
> + pg = maddr_to_page(start);
> + node = phys_to_nid(start);
> + zone = page_to_zone(pg);
> + page_list_del(pg, &heap(node, zone, order));
> +
> + __alloc_heap_pages(pg, order, memflags, d);
I agree with Julien in not seeing how this can be safe / correct.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |