Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

On 8/23/2017 5:20 PM, Konrad Rzeszutek Wilk wrote: ..snip.. Acked-by: Roger Pau Monné Forgot to add, this needs to be backported to stable branches, so: Annie, could you resend the patch with the tags and an update to the description to me please? Done Thanks Annie

Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

On 8/23/2017 5:20 PM, Konrad Rzeszutek Wilk wrote: ..snip.. Acked-by: Roger Pau Monné Forgot to add, this needs to be backported to stable branches, so: Annie, could you resend the patch with the tags and an update to the description to me please? Done Thanks Annie Cc:

[PATCH v2 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

previous to(including) first busy one get stopped, blkthread of remaining queue will still run. So stop all threads properly and return -EBUSY if any queue has inflight I/O. Signed-off-by: Annie Li <annie...@oracle.com> Reviewed-by: Herbert van den Bergh <herbert.van.den.be...@or

[PATCH v2 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

previous to(including) first busy one get stopped, blkthread of remaining queue will still run. So stop all threads properly and return -EBUSY if any queue has inflight I/O. Signed-off-by: Annie Li Reviewed-by: Herbert van den Bergh Reviewed-by: Bhavesh Davda Reviewed-by: Adnan Misherfi Acked-

Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

On 8/18/2017 5:14 AM, Roger Pau Monné wrote: On Thu, Aug 17, 2017 at 06:43:46PM -0400, Annie Li wrote: If there is inflight I/O in any non-last queue, blkback returns -EBUSY directly, and never stops thread of remaining queue and processs them. When removing vbd device with lots of disk I/O

Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

On 8/18/2017 5:14 AM, Roger Pau Monné wrote: On Thu, Aug 17, 2017 at 06:43:46PM -0400, Annie Li wrote: If there is inflight I/O in any non-last queue, blkback returns -EBUSY directly, and never stops thread of remaining queue and processs them. When removing vbd device with lots of disk I/O

[PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

properly and return -EBUSY if any queue has inflight I/O. Signed-off-by: Annie Li <annie...@oracle.com> Reviewed-by: Herbert van den Bergh <herbert.van.den.be...@oracle.com> Reviewed-by: Bhavesh Davda <bhavesh.da...@oracle.com> Reviewed-by: Adnan Misherfi <adnan.mishe...@oracle.co

[PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

properly and return -EBUSY if any queue has inflight I/O. Signed-off-by: Annie Li Reviewed-by: Herbert van den Bergh Reviewed-by: Bhavesh Davda Reviewed-by: Adnan Misherfi --- drivers/block/xen-blkback/xenbus.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers

Re: [Xen-devel] [PATCH net-next v2 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy

On 2013/12/13 7:48, Zoltan Kiss wrote: A long known problem of the upstream netback implementation that on the TX path (from guest to Dom0) it copies the whole packet from guest memory into Dom0. That simply became a bottleneck with 10Gb NICs, and generally it's a huge perfomance penalty. The

Re: [Xen-devel] [PATCH net-next v2 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy

On 2013/12/13 7:48, Zoltan Kiss wrote: A long known problem of the upstream netback implementation that on the TX path (from guest to Dom0) it copies the whole packet from guest memory into Dom0. That simply became a bottleneck with 10Gb NICs, and generally it's a huge perfomance penalty. The

Re: [Xen-devel] [PATCH v2] xen/grant-table: correctly initialize grant table version 1

On 2013-1-10 17:16, Matt Wilson wrote: On Wed, Jan 09, 2013 at 12:02:09PM +, Ian Campbell wrote: On Wed, 2013-01-09 at 02:40 +, ANNIE LI wrote: @@ -1080,18 +1081,18 @@ static void gnttab_request_version(void) panic("we need grant tables version 2, but only vers

Re: [Xen-devel] [PATCH v2] xen/grant-table: correctly initialize grant table version 1

On 2013-1-10 17:16, Matt Wilson wrote: On Wed, Jan 09, 2013 at 12:02:09PM +, Ian Campbell wrote: On Wed, 2013-01-09 at 02:40 +, ANNIE LI wrote: @@ -1080,18 +1081,18 @@ static void gnttab_request_version(void) panic(we need grant tables version 2, but only version 1

Re: [Xen-devel] [PATCH v2] xen/grant-table: correctly initialize grant table version 1

On 2013-1-9 20:02, Ian Campbell wrote: On Wed, 2013-01-09 at 02:40 +, ANNIE LI wrote: @@ -1080,18 +1081,18 @@ static void gnttab_request_version(void) panic("we need grant tables version 2, but only version 1 is available");

Re: [Xen-devel] [PATCH v2] xen/grant-table: correctly initialize grant table version 1

On 2013-1-9 20:02, Ian Campbell wrote: On Wed, 2013-01-09 at 02:40 +, ANNIE LI wrote: @@ -1080,18 +1081,18 @@ static void gnttab_request_version(void) panic(we need grant tables version 2, but only version 1 is available); } else

Re: [Xen-devel] [PATCH v2] xen/grant-table: correctly initialize grant table version 1

st_version() early so that grant_table_version and grefs_per_grant_frame can be appropriately set. A few BUG_ON()s have been added to prevent this type of bug from reoccurring in the future. Signed-off-by: Matt Wilson Reviewed-and-Tested-by: Steven Noonan Cc: Ian Campbell Cc: Konrad Rzeszutek Wilk Cc: A

Re: [Xen-devel] [PATCH v2] xen/grant-table: correctly initialize grant table version 1

Thanks so much for posting this. On 2013-1-6 19:14, Matt Wilson wrote: Commit 85ff6acb075a484780b3d763fdf41596d8fc0970 (xen/granttable: Grant tables V2 implementation) changed the GREFS_PER_GRANT_FRAME macro from a constant to a conditional expression. The expression depends on