Re: [Xen-devel] [PATCH 1/6] mmu: Introduce XENMEM_claim_pages (subop of memory ops).

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> > > The big thing is *might*. I put this in the code path to explain better:
> > > 
> > >   /* note; The usage of tmem claim means that allocation from a guest 
> > > *might*
> > > +     * have to come from freeable memory. Using free memory is always 
> > > better, if
> > > +     * it is available, than using freeable memory. This flag is for the 
> > > use
> > > +     * case where the toolstack cannot be constantly aware of the exact 
> > > current
> > > +     * value of free and/or freeable on each machine and is multi-machine
> > > +     * capable. It can try/fail a "normal" claim on all machines first 
> > > then,
> > > +     * and if the normal claim on all machines fail, then "fallback" to a
> > > +     * tmem-flag type claim.
> > 
> > Oh I see.  That's pretty strange semantics for a 'claim', though.
> > Wouldn't it make sense for the toolstack just to query free and claimed
> > memory on the first pass and fail if there's not enough space?
> 
> So do something like this:
> 
>       if ( dom->claim_enabled ) {
>               unsigned long outstanding = 
> xc_domain_get_outstanding_pages(dom->xch);
>               xc_physinfo_t xcphysinfo = { 0 };
>               int flag = XENMEMF_claim_normal;
>       
>               rc = xc_physinfo(dom->xch, &xcphysinfo);
> 
>               if (xcphysinfo.total_pages + outstanding > dom->total_pages)
>                       flag = XENMEMF_claim_tmem;
> 
>               rc = xc_domain_claim_pages(dom->xch, dom->guest_domid, 
> dom->total_pages,
>                                          flag);
>       }
> 
> (Ignorning the checks for 'rc' and bailing out as neccessary)
> 
> > The race between that query and the claim call (i.e. enough
> > actually-free space at query time but only freeable memory at claim
> > time) isn't materially different from the claim succeeding and then tmem
> > consuming the memory.  And a race between multiple claims can be
> > trivially avoided with a mutex in toolstack.
> 
> The location where the claim call is in the libxc toolstack (it seemed
> the most appropiate as it deals with the populate calls). There is no locking
> semantics at all in that library - that is something the other libraries - 
> such as libxl, have. The libxl has the lock, but it would be a coarse lock
> as it would be around:

..bla bla..

The other thought is just to drop the XENMEMF_claim_normal flag
and just have XENMEMF_claim_tmem flag and use that by default.

I think that will simplify this a lot more. Let me prep a patch
and have it ready by tomorrow.

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