Re: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.10.12 at 17:04, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
>> 
>> >>> On 30.10.12 at 18:13, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> 
> (NOTE TO KEIR: Input from you requested in first stanza below.)
> 
> Hi Jan --
> 
> Thanks for the continued feedback!
> 
> I've slightly re-ordered the email to focus on the problem
> (moved tmem-specific discussion to the end).
> 
>> As long as the allocation times can get brought down to an
>> acceptable level, I continue to not see a need for the extra
>> "claim" approach you're proposing. So working on that one (or
>> showing that without unreasonable effort this cannot be
>> further improved) would be a higher priority thing from my pov
>> (without anyone arguing about its usefulness).
> 
> Fair enough.  I will do some measurement and analysis of this
> code.  However, let me ask something of you and Keir as well:
> Please estimate how long (in usec) you think it is acceptable
> to hold the heap_lock.  If your limit is very small (as I expect),
> doing anything "N" times in a loop with the lock held (for N==2^26,
> which is a 256GB domain) may make the analysis moot.

I think your thoughts here simply go a different route than mine:
Of course it is wrong to hold _any_ lock for extended periods of
time. But extending what was done by c/s 26056:177fdda0be56
might, considering the effect that change had, buy you quite a
bit of allocation efficiency.

Jan


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