[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(&gt->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


 


Rackspace

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