|
[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 |