Re: Proposed new "memory capacity claim" hypercall/feature

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> 
> >>> On 31.10.12 at 17:04, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> >>
> >> 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.

No, I think we are on the same route, except that maybe I
am trying to take a shortcut to the end. :-)

I did follow the discussion that led to that changeset
and highly recommended to the Oracle product folks that
we integrate it asap.

But reducing the domain allocation time "massively" from
30 sec to 3 sec doesn't help solve my issue because, in
essence, my issue says that the heap_lock must still be
held for most of that 3 sec.  Even reducing it by _another_
factor of 10 to 0.3 sec or a factor of 100 to 30msec
doesn't solve my problem.

To look at it another way, the code in alloc_heap_page()
contained within the loop:

	for ( i = 0; i < (1 << order); i++ )

may be already unacceptable, even _after_ the patch, if
order==26 (a fictional page size just for this illustration)
because the heap_lock will be held for a very very long time.
(In fact for order==20, 1GB pages, it could already be a
problem.)

The claim hypercall/subop would allocate _capacity_ only,
and then the actual physical pages are "lazily" allocated
from that pre-allocated capacity.

Anyway, I am still planning on proceeding with some
of the measurement/analysis _and_ proof-of-concept.

Thanks,
Dan