[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.