[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/6] mmu: Introduce XENMEM_claim_pages (subop of memory ops).
Hi, At 12:47 -0500 on 04 Mar (1362401229), Konrad Rzeszutek Wilk wrote: > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -252,11 +252,124 @@ static long midsize_alloc_zone_pages; > #define MIDSIZE_ALLOC_FRAC 128 > > static DEFINE_SPINLOCK(heap_lock); > +static long total_unclaimed_pages; /* total outstanding claims by all > domains */ Could this field (& associated per-domain stuff) have a better name? AFAICT from the code, this is a count of _claimed_ pages (specifically, claimed but not allocated). It caused me to double-take almost every time I saw it used in this patch. How about outstanding_claimed_pages, or just outstanding_claims? > unsigned long domain_adjust_tot_pages(struct domain *d, long pages) > { > + long dom_before, dom_after, dom_claimed, sys_before, sys_after; > + > ASSERT(spin_is_locked(&d->page_alloc_lock)); > - return d->tot_pages += pages; > + d->tot_pages += pages; > + > + /* > + * can test d->claimed_pages race-free because it can only change > + * if d->page_alloc_lock and heap_lock are both held, see also > + * domain_set_unclaimed_pages below > + */ > + if ( !d->unclaimed_pages ) > + goto out; > + > + spin_lock(&heap_lock); > + /* adjust domain unclaimed_pages; may not go negative */ > + dom_before = d->unclaimed_pages; > + dom_after = dom_before - pages; > + if ( (dom_before > 0) && (dom_after < 0) ) > + dom_claimed = 0; Why the test for dom_before > 0 ? I think it might be better to BUG_ON() any of these counts ever being negative, rather than to carry on regardless. Or is this meant to be a cunning way of handling the case where sizeof (long) == 4 and unclaimed_pages > 2^31 ? I suspect that will fall foul of the undefinedness of signed overflow. > + else > + dom_claimed = dom_after; > + d->unclaimed_pages = dom_claimed; > + /* flag accounting bug if system unclaimed_pages would go negative */ > + sys_before = total_unclaimed_pages; > + sys_after = sys_before - (dom_before - dom_claimed); > + BUG_ON((sys_before > 0) && (sys_after < 0)); Same question here. > +/* > + * XENMEM_claim_pages flags: > + * normal: claim is successful only if sufficient free pages > + * are available. > + * tmem: claim is successful only if sufficient free pages > + * are available and (if tmem is enabled) hypervisor > + * may also consider tmem "freeable" pages to satisfy the claim. The 'normal' restriction isn't actually enforced except at claim time. Since the gate in alloc_heap_pages is effectively: (request > free + freeable - total_reserved) later allocations (from any source) can take up all the free memory as long as freeable >= total_reserved). Is there a use for it? Presumably by turning on tmem you're happy with the idea that allocations might have to come from freeable memory? Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |