Re: [Xen-devel] [RFC/PATCH] XENMEM_claim_pages (subop of an existing) hypercall

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> Sent: Wednesday, November 14, 2012 12:24 AM
> To: Dan Magenheimer; Jan Beulich; TimDeegan
> Cc: xen-devel@xxxxxxxxxxxxx; Zhigang Wang; Konrad Rzeszutek Wilk
> Subject: Re: [RFC/PATCH] XENMEM_claim_pages (subop of an existing) hypercall
> 
> On 13/11/2012 22:23, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:
> 
> > The key variables (d->unclaimed_pages and total_unclaimed_pages)
> > start at zero if no claim has yet been staked for any domain.
> > (Perhaps a better name is "claimed_but_not_yet_possessed" but that's
> > a bit unwieldy.)  If no claim hypercalls are executed, there
> > should be no impact on existing usage.

Hi Keir --

Thanks for the feedback!

> It would be nice if d->tot_pages adjustments didn't take the global
> heap_lock in this case. There's probably some way to bail out of those new
> update functions before doing the locked work, in that case.

I agree.  I played with atomics for a bit but couldn't
see a way it would work without races.  The generic
pseudo-code is

        if (A) {
                atomically {
                        modify A
                        modify d->B
                }
        } else {
                modify d->B
        }

Any ideas?

Or possibly if your suggestion from a couple weeks ago (attached
below) is implemented, the heap_lock will always be held so
briefly in alloc/free_heap_pages that taking heap_lock briefly
in domain_de/increase_tot_pages will no longer be an issue?

Thanks,
Dan

> -----Original Message-----
> From: Keir Fraser [mailto:keir@xxxxxxx]
> Sent: Friday, November 02, 2012 3:30 AM
> To: Jan Beulich; Dan Magenheimer
> Cc: Olaf Hering; IanCampbell; George Dunlap; Ian Jackson; George Shuklin; 
> DarioFaggioli; xen-
> devel@xxxxxxxxxxxxx; Konrad Rzeszutek Wilk; Kurt Hackel; Mukesh Rathor; 
> Zhigang Wang; TimDeegan
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 02/11/2012 09:01, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
> > Plus, if necessary, that loop could be broken up so that only the
> > initial part of it gets run with the lock held (see c/s
> > 22135:69e8bb164683 for why the unlock was moved past the
> > loop). That would make for a shorter lock hold time, but for a
> > higher allocation latency on large oder allocations (due to worse
> > cache locality).
> 
> In fact I believe only the first page needs to have its count_info set to !=
> PGC_state_free, while the lock is held. That is sufficient to defeat the
> buddy merging in free_heap_pages(). Similarly, we could hoist most of the
> first loop in free_heap_pages() outside the lock. There's a lot of scope for
> optimisation here.
> 
>  -- Keir

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel