[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv10 4/4] gnttab: use per-VCPU maptrack free lists
>>> On 26.05.15 at 20:00, <david.vrabel@xxxxxxxxxx> wrote: > v10: > - Divide max_maptrack_frames evenly amongst the VCPUs. > - Increase default max_maptrack_frames to compensate. I'm not really happy about this, but also can't immediately suggest a better model (without removing maptrack frames from vCPU-s). I'd really like to hear opinions of others, namely maintainers, regarding this resource use issue. Should we perhaps start accounting maptrack frames against the domain's allocation (i.e. a domain can get as many as it likes beyond the set limit, provided it ballooned out suitably many pages up front)? > --- a/xen/common/grant_table.c > +++ b/xen/common/grant_table.c > @@ -57,7 +57,7 @@ integer_param("gnttab_max_frames", max_grant_frames); > * New options allow to set max_maptrack_frames and > * map_grant_table_frames independently. > */ > -#define DEFAULT_MAX_MAPTRACK_FRAMES 256 > +#define DEFAULT_MAX_MAPTRACK_FRAMES 1024 Apart from everything else this again results in ... > @@ -1457,6 +1491,17 @@ gnttab_setup_table( > gt = d->grant_table; > write_lock(>->lock); > > + /* Tracking of mapped foreign frames table */ > + gt->maptrack = xzalloc_array(struct grant_mapping *, > max_maptrack_frames); ... this becoming an order-1 runtime allocation on other than 32-bit ARM. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |