qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Xen-devel] [PATCH] qemu/xendisk: set maximum number of


From: Jan Beulich
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] qemu/xendisk: set maximum number of grants to be used
Date: Fri, 11 May 2012 15:19:20 +0100

>>> On 11.05.12 at 09:19, "Jan Beulich" <address@hidden> wrote:
> Legacy (non-pvops) gntdev drivers may require this to be done when the
> number of grants intended to be used simultaneously exceeds a certain
> driver specific default limit.
> 
> Signed-off-by: Jan Beulich <address@hidden>
> 
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice *
>      if (xen_mode != XEN_EMULATE) {
>          batch_maps = 1;
>      }
> +    if (xc_gnttab_set_max_grants(xendev->gnttabdev,
> +            max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0)

In more extensive testing it appears that very rarely this value is still
too low:

xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 342 maps)

342 + 11 = 353 > 352 = 32 * 11

Could someone help out here? I first thought this might be due to
use_aio being non-zero, but ioreq_start() doesn't permit more than
max_requests struct ioreqs-s to be around.

Additionally, shouldn't the driver be smarter and gracefully handle
grant mapping failures (as the per-domain map track table in the
hypervisor is a finite resource)?

Jan

> +        xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",
> +                      strerror(errno));
>  }
>  
>  static int blk_init(struct XenDevice *xendev)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]