[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. ~Andrew
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |