[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 1/2] hypervisor: XENMEM_claim_pages (subop of existing) hypercall
>>> On 26.11.12 at 19:11, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote: > +unsigned long domain_increase_tot_pages(struct domain *d, unsigned long > pages) > +{ > + long dom_before, dom_after, dom_claimed, sys_before, sys_after; > + > + ASSERT(spin_is_locked(&d->page_alloc_lock)); > + if ( !d->unclaimed_pages ) > + return d->tot_pages += pages; So after the conditional adjustment above, I fail to see where d->tot_pages would get adjusted in the code below. Which gets me to ask ... > + spin_lock(&heap_lock); > + dom_before = d->unclaimed_pages; > + dom_after = dom_before - pages; > + if ( (dom_before > 0) && (dom_after < 0) ) > + dom_claimed = 0; > + else > + dom_claimed = dom_after; > + sys_before = total_unclaimed_pages; > + sys_after = sys_before - (dom_before - dom_claimed); > + BUG_ON( (sys_before > 0) && (sys_after < 0) ); > + total_unclaimed_pages = sys_after; > + d->unclaimed_pages = dom_claimed; > + spin_unlock(&heap_lock); > + return d->tot_pages; > +} ...: Is there actually a strong reason why there needs to be an "increase" and a "decrease" version of this, rather than just having an "adjust" operation with a signed page count parameter? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |