[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] gnttab: defer allocation of status frame tracking array

On 23/12/2020 15:13, Jan Beulich wrote:
> This array can be large when many grant frames are permitted; avoid
> allocating it when it's not going to be used anyway, by doing this only
> in gnttab_populate_status_frames().
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v2: Defer allocation to when a domain actually switches to the v2 grant
>     API.

I see this as a backwards step.  It turns a build-time -ENOMEM into a
runtime -ENOMEM, and if you recall from one of the XSAs, the Windows PV
drivers will BUG() if set_version fails.  (Yes - this is dumb behaviour,
but it is in the field now.)

It is the toolstack's responsibility to not over-extend the capabilities
of the host, but this is impossible to do with behaviour like this. 
Failing at domain creation time is a whole lot less bad for the system
as a whole.

Longer term, allocations like this ought to come from some per-domain
pool (possibly not shared with the shadow memory pool), which can be
sized suitably at create time.

This is one of the points behind introducing dmalloc()/etc in the
fault-injection series.  At the moment, we have absolutely no clue what
the memory overhead of a domain is in Xen.  It is impossible to
calculate how many VMs will fit on a host, because the only way you can
answer the question is to attempt to create them all.

Understanding how much memory a domain actually takes is the first
step.  Creating a plausible bound is the second step, and that will be
of substantial use to higher level management software.




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