Re: [Qemu-devel] [PATCH v6 11/11] migration: create a dedicated thread to release rdma resource

On Fri, Aug 17, 2018 at 10:59 PM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> ibv_dereg_mr wait for a long time for big memory size virtual server. >> >> The test result is: >> 10GB 326ms >> 20GB 699ms >> 30GB 1021ms >> 40GB 1387ms >> 50GB 1712ms

Re: [Qemu-devel] [PATCH v6 10/11] migration: remove the unnecessary RDMA_CONTROL_ERROR message

On Fri, Aug 17, 2018 at 10:04 PM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> It's not necessary to send RDMA_CONTROL_ERROR when clean up rdma resource. >> If rdma->error_state is ture, the message may not send successfully. >> and the cm event can also notify

Re: [Qemu-devel] [PATCH v6 09/11] migration: poll the cm event for destination qemu

On Fri, Aug 17, 2018 at 10:01 PM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> The destination qemu only poll the comp_channel->fd in >> qemu_rdma_wait_comp_channel. But when source qemu disconnnect >> the rdma connection, the destination qemu should be

Re: [Qemu-devel] [PATCH v6 03/12] migration: avoid concurrent invoke channel_close by different threads

This patch causes compile error when make check. LINKtests/test-qdist migration/qemu-file.o: In function `qemu_fclose': /tmp/qemu-test/src/migration/qemu-file.c:331: undefined reference to `migrate_get_current' /tmp/qemu-test/src/migration/qemu-file.c:333: undefined reference to

Re: [Qemu-devel] [PATCH v6 00/12] Enable postcopy RDMA live migration

There is one compile error, please ignore those patch, I will send a new version patch. On Fri, Aug 3, 2018 at 5:13 PM, Lidong Chen wrote: > The RDMA QIOChannel does not support bi-directional communication, so when > RDMA > live migration with postcopy enabled, the source qemu return path get

Re: [Qemu-devel] [PATCH v5 08/10] migration: create a dedicated thread to release rdma resource

On Mon, Jul 23, 2018 at 10:54 PM, Gal Shachaf wrote: > On Thu, Jul 5, 2018 at 10:26 PM, 858585 jemmy wrote: >> On Thu, Jun 28, 2018 at 2:59 AM, Dr. David Alan Gilbert >> wrote: >>> * Lidong Chen (jemmy858...@gmail.com) wrote: >>>> ibv_dereg_mr wait for a l

Re: [Qemu-devel] [PATCH v5 08/10] migration: create a dedicated thread to release rdma resource

On Thu, Jul 5, 2018 at 10:26 PM, 858585 jemmy wrote: > On Thu, Jun 28, 2018 at 2:59 AM, Dr. David Alan Gilbert > wrote: >> * Lidong Chen (jemmy858...@gmail.com) wrote: >>> ibv_dereg_mr wait for a long time for big memory size virtual server. >>> >>>

Re: [Qemu-devel] [PATCH] migration: release MigrationIncomingState in migration_object_finalize

On Thu, Jul 12, 2018 at 12:08 PM, 858585 jemmy wrote: > On Fri, Jul 6, 2018 at 6:41 PM, Dr. David Alan Gilbert > wrote: >> * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote: >>> * Lidong Chen (jemmy858...@gmail.com) wrote: >>> > Qemu initialize the

Re: [Qemu-devel] [PATCH] migration: release MigrationIncomingState in migration_object_finalize

On Fri, Jul 6, 2018 at 6:41 PM, Dr. David Alan Gilbert wrote: > * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote: >> * Lidong Chen (jemmy858...@gmail.com) wrote: >> > Qemu initialize the MigrationIncomingState structure in >> > migration_object_init, >> > but not release it. this patch

Re: [Qemu-devel] [PATCH v5 08/10] migration: create a dedicated thread to release rdma resource

On Thu, Jun 28, 2018 at 2:59 AM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> ibv_dereg_mr wait for a long time for big memory size virtual server. >> >> The test result is: >> 10GB 326ms >> 20GB 699ms >> 30GB 1021ms >> 40GB 1387ms >> 50GB 1712ms

Re: [Qemu-devel] [PATCH v5 04/10] migration: implement bi-directional RDMA QIOChannel

On Wed, Jun 13, 2018 at 10:21 PM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> From: Lidong Chen >> >> This patch implements bi-directional RDMA QIOChannel. Because different >> threads may access RDMAQIOChannel currently, this patch use RCU to protect >> it.

Re: [Qemu-devel] [PATCH v5 09/10] migration: poll the cm event while wait RDMA work request completion

On Wed, Jun 13, 2018 at 10:24 PM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> If the peer qemu is crashed, the qemu_rdma_wait_comp_channel function >> maybe loop forever. so we should also poll the cm event fd, and when >> receive RDMA_CM_EVENT_DISCONNECTED and

Re: [Qemu-devel] [PATCH v4 11/12] migration: poll the cm event while wait RDMA work request completion

t; On 5/31/2018 10:36 AM, 858585 jemmy wrote: >> >> On Thu, May 31, 2018 at 1:33 AM, Dr. David Alan Gilbert >> wrote: >>> >>> * Lidong Chen (jemmy858...@gmail.com) wrote: >>>> >>>> If the peer qemu is crashed, the qemu_rdma_wait_comp_channe

Re: [Qemu-devel] [PATCH v4 04/12] migration: avoid concurrent invoke channel_close by different threads

On Sun, Jun 3, 2018 at 9:50 PM, 858585 jemmy wrote: > On Thu, May 31, 2018 at 6:52 PM, Dr. David Alan Gilbert > wrote: >> * 858585 jemmy (jemmy858...@gmail.com) wrote: >>> On Wed, May 30, 2018 at 10:45 PM, Dr. David Alan Gilbert >>> wrote: >>> > *

Re: [Qemu-devel] [PATCH v4 04/12] migration: avoid concurrent invoke channel_close by different threads

On Thu, May 31, 2018 at 6:52 PM, Dr. David Alan Gilbert wrote: > * 858585 jemmy (jemmy858...@gmail.com) wrote: >> On Wed, May 30, 2018 at 10:45 PM, Dr. David Alan Gilbert >> wrote: >> > * Lidong Chen (jemmy858...@gmail.com) wrote: >> >> From: Lidong Chen

Re: [Qemu-devel] [PATCH v4 10/12] migration: create a dedicated thread to release rdma resource

On Thu, May 31, 2018 at 6:55 PM, Dr. David Alan Gilbert wrote: > * 858585 jemmy (jemmy858...@gmail.com) wrote: >> On Thu, May 31, 2018 at 12:50 AM, Dr. David Alan Gilbert >> wrote: >> > * Lidong Chen (jemmy858...@gmail.com) wrote: >> >> ibv_dereg_mr wait

Re: [Qemu-devel] [PATCH v4 11/12] migration: poll the cm event while wait RDMA work request completion

On Thu, May 31, 2018 at 1:33 AM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> If the peer qemu is crashed, the qemu_rdma_wait_comp_channel function >> maybe loop forever. so we should also poll the cm event fd, and when >> receive any cm event, we consider some

Re: [Qemu-devel] [PATCH v4 10/12] migration: create a dedicated thread to release rdma resource

On Thu, May 31, 2018 at 12:50 AM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> ibv_dereg_mr wait for a long time for big memory size virtual server. >> >> The test result is: >> 10GB 326ms >> 20GB 699ms >> 30GB 1021ms >> 40GB 1387ms >> 50GB 1712ms

Re: [Qemu-devel] [PATCH v4 04/12] migration: avoid concurrent invoke channel_close by different threads

On Wed, May 30, 2018 at 10:45 PM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> From: Lidong Chen >> >> The channel_close maybe invoked by different threads. For example, source >> qemu invokes qemu_fclose in main thread, migration thread and return path >>

Re: [Qemu-devel] [PATCH v3 5/6] migration: implement bi-directional RDMA QIOChannel

ping. On Mon, May 21, 2018 at 7:49 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Wed, May 16, 2018 at 5:36 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: >> On Tue, May 15, 2018 at 10:54 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >>> On

Re: [Qemu-devel] [PATCH 2/2] migration: not wait RDMA_CM_EVENT_DISCONNECTED event after rdma_disconnect

On Wed, May 16, 2018 at 9:13 PM, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > * 858585 jemmy (jemmy858...@gmail.com) wrote: > > > >> >> >> > I wonder why dereg_mr takes so long - I could understand if reg_mr >> >> >> > took a

Re: [Qemu-devel] [PATCH v3 5/6] migration: implement bi-directional RDMA QIOChannel

On Wed, May 16, 2018 at 5:36 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Tue, May 15, 2018 at 10:54 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >> On 05/05/2018 16:35, Lidong Chen wrote: >>> @@ -2635,12 +2637,20 @@ static ssize_t qio_channel_rd

Re: [Qemu-devel] FW: [PATCH 2/2] migration: not wait RDMA_CM_EVENT_DISCONNECTED event after rdma_disconnect

On Thu, May 17, 2018 at 3:31 PM, Aviad Yehezkel <avia...@dev.mellanox.co.il> wrote: > > > On 5/17/2018 5:42 AM, 858585 jemmy wrote: >> >> On Wed, May 16, 2018 at 11:11 PM, Aviad Yehezkel >> <avia...@dev.mellanox.co.il> wrote: >>> >>> Hi

Re: [Qemu-devel] [PATCH 2/2] migration: not wait RDMA_CM_EVENT_DISCONNECTED event after rdma_disconnect

On Wed, May 16, 2018 at 5:53 PM, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > * 858585 jemmy (jemmy858...@gmail.com) wrote: >> On Wed, May 16, 2018 at 5:39 PM, Dr. David Alan Gilbert >> <dgilb...@redhat.com> wrote: >> > * 858585 jemmy (jemmy858...@gm

Re: [Qemu-devel] [PATCH 2/2] migration: not wait RDMA_CM_EVENT_DISCONNECTED event after rdma_disconnect

On Wed, May 16, 2018 at 5:39 PM, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > * 858585 jemmy (jemmy858...@gmail.com) wrote: >> On Tue, May 15, 2018 at 3:27 AM, Dr. David Alan Gilbert >> <dgilb...@redhat.com> wrote: >> > * 858585 jemmy (jemmy858...@gm

Re: [Qemu-devel] [PATCH v3 5/6] migration: implement bi-directional RDMA QIOChannel

On Tue, May 15, 2018 at 10:54 PM, Paolo Bonzini wrote: > On 05/05/2018 16:35, Lidong Chen wrote: >> @@ -2635,12 +2637,20 @@ static ssize_t qio_channel_rdma_writev(QIOChannel >> *ioc, >> { >> QIOChannelRDMA *rioc = QIO_CHANNEL_RDMA(ioc); >> QEMUFile *f =

Re: [Qemu-devel] [PATCH 2/2] migration: not wait RDMA_CM_EVENT_DISCONNECTED event after rdma_disconnect

On Tue, May 15, 2018 at 3:27 AM, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > * 858585 jemmy (jemmy858...@gmail.com) wrote: >> On Sat, May 12, 2018 at 2:03 AM, Dr. David Alan Gilbert >> <dgilb...@redhat.com> wrote: >> > * 858585 jemmy (jemmy858...@g

Re: [Qemu-devel] [PATCH 2/2] migration: not wait RDMA_CM_EVENT_DISCONNECTED event after rdma_disconnect

On Sat, May 12, 2018 at 2:03 AM, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > * 858585 jemmy (jemmy858...@gmail.com) wrote: >> On Wed, May 9, 2018 at 2:40 AM, Dr. David Alan Gilbert >> <dgilb...@redhat.com> wrote: >> > * Lidong Chen (jemmy858...

Re: [Qemu-devel] [PATCH 1/2] migration: implement io_set_aio_fd_handler function for RDMA QIOChannel

On Wed, May 9, 2018 at 1:10 AM, Dr. David Alan Gilbert wrote: > * Juan Quintela (quint...@redhat.com) wrote: >> Lidong Chen wrote: >> > if qio_channel_rdma_readv return QIO_CHANNEL_ERR_BLOCK, the destination >> > qemu >> > crash. >> > >> > The

Re: [Qemu-devel] [PATCH 2/2] migration: not wait RDMA_CM_EVENT_DISCONNECTED event after rdma_disconnect

On Wed, May 9, 2018 at 2:40 AM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> When cancel migration during RDMA precopy, the source qemu main thread hangs >> sometime. >> >> The backtrace is: >> (gdb) bt >> #0 0x7f249eabd43d in

Re: [Qemu-devel] [PATCH 1/2] migration: update index field when delete or qsort RDMALocalBlock

On Wed, May 9, 2018 at 1:19 AM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> rdma_delete_block function deletes RDMALocalBlock base on index field, >> but not update the index field. So when next time invoke rdma_delete_block, >> it will not

Re: [Qemu-devel] [PATCH v3 3/6] migration: remove unnecessary variables len in QIOChannelRDMA

On Tue, May 8, 2018 at 10:19 PM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> Because qio_channel_rdma_writev and qio_channel_rdma_readv maybe invoked >> by different threads concurrently, this patch removes unnecessary variables >> len in

Re: [Qemu-devel] [PATCH v2 4/5] migration: implement bi-directional RDMA QIOChannel

On Fri, Apr 27, 2018 at 5:16 PM, Daniel P. Berrangé <berra...@redhat.com> wrote: > On Fri, Apr 27, 2018 at 03:56:38PM +0800, 858585 jemmy wrote: >> On Fri, Apr 27, 2018 at 1:36 AM, Dr. David Alan Gilbert >> <dgilb...@redhat.com> wrote: >> > * Lidon

Re: [Qemu-devel] [PATCH v2 4/5] migration: implement bi-directional RDMA QIOChannel

On Fri, Apr 27, 2018 at 1:36 AM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> This patch implements bi-directional RDMA QIOChannel. Because different >> threads may access RDMAQIOChannel concurrently, this patch use RCU to >> protect it. >>

Re: [Qemu-devel] [PATCH v2 3/5] migration: remove unnecessary variables len in QIOChannelRDMA

On Fri, Apr 27, 2018 at 12:40 AM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> Because qio_channel_rdma_writev and qio_channel_rdma_readv maybe invoked >> by different threads concurrently, this patch removes unnecessary variables >> len in

Re: [Qemu-devel] [PATCH 2/5] migration: add the interface to set get_return_path

On Thu, Apr 12, 2018 at 4:28 PM, Daniel P. Berrangé wrote: > On Wed, Apr 11, 2018 at 06:18:18PM +0100, Dr. David Alan Gilbert wrote: >> * Lidong Chen (jemmy858...@gmail.com) wrote: >> > The default get_return_path function of iochannel does not work for >> > RDMA live

Re: [Qemu-devel] [PATCH 4/5] migration: fix qemu carsh when RDMA live migration

On Thu, Apr 12, 2018 at 12:43 AM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> After postcopy, the destination qemu work in the dedicated >> thread, so only invoke yield_until_fd_readable before postcopy >> migration. > > The subject line

Re: [Qemu-devel] [PATCH 5/5] migration: disable RDMA WRITR after postcopy started.

On Wed, Apr 11, 2018 at 11:56 PM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> RDMA write operations are performed with no notification to the destination >> qemu, then the destination qemu can not wakeup. So disable RDMA WRITE after >>

Re: [Qemu-devel] [PATCH 0/5] Enable postcopy RDMA live migration

On Wed, Apr 11, 2018 at 8:29 PM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> Current Qemu RDMA communication does not support send and receive >> data at the same time, so when RDMA live migration with postcopy >> enabled, the source qemu

Re: [Qemu-devel] [PATCH 0/5] Enable postcopy RDMA live migration

ping. On Sat, Apr 7, 2018 at 4:26 PM, Lidong Chen wrote: > Current Qemu RDMA communication does not support send and receive > data at the same time, so when RDMA live migration with postcopy > enabled, the source qemu return path thread get qemu file error. > > Those

Re: [Qemu-devel] [PATCH] migration: Fix rate limiting issue on RDMA migration

On Wed, Mar 21, 2018 at 2:19 AM, Juan Quintela wrote: > Lidong Chen wrote: >> RDMA migration implement save_page function for QEMUFile, but >> ram_control_save_page do not increase bytes_xfer. So when doing >> RDMA migration, it will use whole

Re: [Qemu-devel] [PATCH] migration: Fix rate limiting issue on RDMA migration

ping. On Thu, Mar 15, 2018 at 1:33 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Thu, Mar 15, 2018 at 4:19 AM, Dr. David Alan Gilbert > <dgilb...@redhat.com> wrote: >> * Lidong Chen (jemmy858...@gmail.com) wrote: >>> RDMA migration implemen

Re: [Qemu-devel] [PATCH] migration: Fix rate limiting issue on RDMA migration

On Thu, Mar 15, 2018 at 4:19 AM, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858...@gmail.com) wrote: >> RDMA migration implement save_page function for QEMUFile, but >> ram_control_save_page do not increase bytes_xfer. So when doing >> RDMA migration, it will use

Re: [Qemu-devel] [PATCH] migration: Fix rate limiting issue on RDMA migration

Ping. On Sat, Mar 10, 2018 at 10:32 PM, Lidong Chen wrote: > RDMA migration implement save_page function for QEMUFile, but > ram_control_save_page do not increase bytes_xfer. So when doing > RDMA migration, it will use whole bandwidth. > > Signed-off-by: Lidong Chen

Re: [Qemu-devel] [Qemu-block] [PATCH v4] migration/block: move bdrv_is_allocated() into bb's AioContext

On Tue, May 9, 2017 at 4:54 AM, Stefan Hajnoczi wrote: > On Fri, May 05, 2017 at 04:03:49PM +0800, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> when block migration with high-speed, mig_save_device_bulk hold the >> BQL and invoke

Re: [Qemu-devel] [PATCH] migration/block: optimize the performance by coalescing the same write type

Hi Stefan: Could you help me review this patch? Thanks a lot. On Mon, Apr 24, 2017 at 10:03 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > the reason of MIN_CLUSTER_SIZE is 8192 is base on the performance > test result. the performance is only reduce obviously when

Re: [Qemu-devel] [Qemu-block] [PATCH v3] migration/block:limit the time used for block migration

On Wed, May 3, 2017 at 11:44 AM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Mon, Apr 10, 2017 at 9:52 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Sat, Apr 08, 2017 at 09:17:58PM +0800, 858585 jemmy wrote: >>> On Fri, Apr 7, 2017 at 7:34 PM, Stefan

Re: [Qemu-devel] [Qemu-block] [PATCH v3] migration/block:limit the time used for block migration

On Mon, Apr 10, 2017 at 9:52 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Sat, Apr 08, 2017 at 09:17:58PM +0800, 858585 jemmy wrote: >> On Fri, Apr 7, 2017 at 7:34 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: >> > On Fri, Apr 07, 2017 at 09:30:

Re: [Qemu-devel] [PATCH v2] qemu-img: use blk_co_pwrite_zeroes for zero sectors when compressed

On Thu, Apr 27, 2017 at 4:25 AM, Max Reitz wrote: > On 21.04.2017 11:57, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> when the buffer is zero, blk_co_pwrite_zeroes is more effectively than > > s/when/When/, s/effectively/effective/ > >>

Re: [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors

On Wed, Apr 26, 2017 at 3:11 AM, Max Reitz wrote: > On 24.04.2017 17:53, Eric Blake wrote: >> On 04/24/2017 10:47 AM, Eric Blake wrote: >>> On 04/24/2017 10:37 AM, Philippe Mathieu-Daudé wrote: >>> >> /* >> - * Returns true iff the first sector pointed to by 'buf'

Re: [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors

On Mon, Apr 24, 2017 at 11:53 PM, Eric Blake wrote: > On 04/24/2017 10:47 AM, Eric Blake wrote: >> On 04/24/2017 10:37 AM, Philippe Mathieu-Daudé wrote: >> > /* > - * Returns true iff the first sector pointed to by 'buf' contains at > least > - * a non-NUL

Re: [Qemu-devel] [PATCH 1/2] qemu-img: make sure contain the consecutive number of zero bytes

On Mon, Apr 24, 2017 at 10:43 PM, Eric Blake wrote: > On 04/23/2017 09:33 AM, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> is_allocated_sectors_min don't guarantee to contain the >> consecutive number of zero bytes. this patch fixes this bug.

Re: [Qemu-devel] [PATCH] migration/block: optimize the performance by coalescing the same write type

the reason of MIN_CLUSTER_SIZE is 8192 is base on the performance test result. the performance is only reduce obviously when cluster_size is less than 8192. I write this code, run in guest os. to create the worst condition. #include #include #include int main() { char *zero; char

Re: [Qemu-devel] [PATCH v2] qemu-img: use blk_co_pwrite_zeroes for zero sectors when compressed

Hi Everyone: Any suggestion about this patch? Thanks. On Sun, Apr 23, 2017 at 5:53 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > I test four test case for this patch. > 1.qcow2 image with lots of zero cluster, and convert with compress > 2.qcow2 image with lots

Re: [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 24, 2017 at 8:36 PM, Fam Zheng <f...@redhat.com> wrote: > On Mon, 04/24 20:26, 858585 jemmy wrote: >> > 2) qcow2 with cluster_size = 512 is probably too uncommon to be optimized >> > for. >> if culster_size is very small, should disable metadata check

Re: [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 24, 2017 at 8:19 PM, Fam Zheng wrote: > On Mon, 04/24 20:09, Fam Zheng wrote: >> It's a separate problem. > > To be specific: > > 1) there is an option "overlap-check" that one can use to > disable the costly metadata check; yes, i will disable metadata check, and

Re: [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 24, 2017 at 8:09 PM, Fam Zheng <f...@redhat.com> wrote: > On Mon, 04/24 19:54, 858585 jemmy wrote: >> On Mon, Apr 24, 2017 at 3:40 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: >> > On Mon, Apr 17, 2017 at 12:00 PM, 858585 jemmy <jemmy858...@gmail.co

Re: [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 24, 2017 at 3:40 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Mon, Apr 17, 2017 at 12:00 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: >> On Mon, Apr 17, 2017 at 11:49 AM, Fam Zheng <f...@redhat.com> wrote: >>> On Fri, 04/14 14:30, 85858

Re: [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 17, 2017 at 12:00 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Mon, Apr 17, 2017 at 11:49 AM, Fam Zheng <f...@redhat.com> wrote: >> On Fri, 04/14 14:30, 858585 jemmy wrote: >>> Do you know some other format which have very small cluster size? &g

Re: [Qemu-devel] [PATCH] qemu-img: use blk_co_pwrite_zeroes for zero sectors when compressed

On Fri, Apr 21, 2017 at 1:37 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Fri, Apr 21, 2017 at 10:58 AM, 858585 jemmy <jemmy858...@gmail.com> wrote: >> On Thu, Apr 20, 2017 at 6:00 PM, Kevin Wolf <kw...@redhat.com> wrote: >>> Am 20.04.2017 um 10:38 h

Re: [Qemu-devel] [PATCH v2] qemu-img: use blk_co_pwrite_zeroes for zero sectors when compressed

I test four test case for this patch. 1.qcow2 image with lots of zero cluster, and convert with compress 2.qcow2 image with lots of zero cluster, and convert with no compress 3.qcow2 image with lots of non-zero clusters, and convert with compress 4.qcow2 image with lots of non-zero clusters, and

Re: [Qemu-devel] [PATCH] qemu-img: use blk_co_pwrite_zeroes for zero sectors when compressed

On Fri, Apr 21, 2017 at 10:58 AM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Thu, Apr 20, 2017 at 6:00 PM, Kevin Wolf <kw...@redhat.com> wrote: >> Am 20.04.2017 um 10:38 hat jemmy858...@gmail.com geschrieben: >>> From: Lidong Chen <lidongc...@tencent.com

Re: [Qemu-devel] [PATCH] qemu-img: use blk_co_pwrite_zeroes for zero sectors when compressed

On Thu, Apr 20, 2017 at 6:00 PM, Kevin Wolf wrote: > Am 20.04.2017 um 10:38 hat jemmy858...@gmail.com geschrieben: >> From: Lidong Chen >> >> when the buffer is zero, blk_co_pwrite_zeroes is more effectively than >> blk_co_pwritev with

Re: [Qemu-devel] [PATCH v2] qemu-img: check bs_n when use old style option

On Thu, Apr 20, 2017 at 5:33 PM, Kevin Wolf wrote: > Am 20.04.2017 um 11:19 hat jemmy858...@gmail.com geschrieben: >> From: Lidong Chen >> >> When use old style option like -o backing_file, img_convert >> continue run when bs_n > 1, this patch fix this

Re: [Qemu-devel] [PATCH v2] qemu-img: check bs_n when use old style option

test result for this patch: qemu-img convert -c -p -o backing_file=/baseimage/img2015122818606660/img2015122818606660.qcow2 -O qcow2 /data/img2017041611162809.qcow2 /data/img2017041611162809.qcow2 /mnt/img2017041611162809_zip_new.qcow2 qemu-img: Specifying backing image makes no sense when

Re: [Qemu-devel] [PATCH] qemu-img: use blk_co_pwrite_zeroes for zero sectors when compressed

On Thu, Apr 20, 2017 at 4:38 PM, wrote: > From: Lidong Chen > > when the buffer is zero, blk_co_pwrite_zeroes is more effectively than > blk_co_pwritev with BDRV_REQ_WRITE_COMPRESSED. this patch can reduces > the time when converts the qcow2 image

Re: [Qemu-devel] [PATCH] qemu-img: check bs_n when use old style option

On Thu, Apr 20, 2017 at 4:11 PM, Fam Zheng <f...@redhat.com> wrote: > On Thu, 04/20 15:59, 858585 jemmy wrote: >> On Thu, Apr 20, 2017 at 3:51 PM, Fam Zheng <f...@redhat.com> wrote: >> > On Thu, 04/20 12:04, jemmy858...@gmail.com wrote: >> >>

Re: [Qemu-devel] [PATCH] qemu-img: check bs_n when use old style option

On Thu, Apr 20, 2017 at 3:51 PM, Fam Zheng wrote: > On Thu, 04/20 12:04, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> When use old style option like -o backing_file, img_convert >> continue run when bs_n > 1, this patch fix this bug. >> >>

Re: [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 17, 2017 at 11:49 AM, Fam Zheng <f...@redhat.com> wrote: > On Fri, 04/14 14:30, 858585 jemmy wrote: >> Do you know some other format which have very small cluster size? > > 64k is the default cluster size for qcow2 but it can be configured at image > cre

Re: [Qemu-devel] [Qemu-block] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Fri, Apr 14, 2017 at 2:38 PM, Stefan Hajnoczi wrote: > On Fri, Apr 14, 2017 at 7:00 AM, Fam Zheng wrote: >> On Thu, 04/13 10:34, jemmy858...@gmail.com wrote: >>> From: Lidong Chen >>> >>> BLOCK_SIZE is (1 << 20), qcow2 cluster size

Re: [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Fri, Apr 14, 2017 at 2:00 PM, Fam Zheng wrote: > On Thu, 04/13 10:34, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default, >> this may cause the qcow2 file size to be bigger after

Re: [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Thu, Apr 13, 2017 at 10:16 PM, Stefan Hajnoczi wrote: > On Thu, Apr 13, 2017 at 10:34:28AM +0800, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default, >> this may cause the qcow2

Re: [Qemu-devel] migrate -b problems

it this bug? https://bugs.launchpad.net/qemu/+bug/1681688 On Wed, Apr 12, 2017 at 5:18 PM, Kevin Wolf wrote: > Hi all, > > after getting assertion failure reports for block migration in the last > minute, we just hacked around it by commenting out op blocker assertions > for

Re: [Qemu-devel] [PATCH v4] migration/block: use blk_pwrite_zeroes for each zero cluster

On Wed, Apr 12, 2017 at 9:27 AM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Tue, Apr 11, 2017 at 11:59 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: >> On Tue, Apr 11, 2017 at 08:05:12PM +0800, jemmy858...@gmail.com wrote: >>> From: Lidong Chen <lidongc..

Re: [Qemu-devel] [PATCH v4] migration/block: use blk_pwrite_zeroes for each zero cluster

On Tue, Apr 11, 2017 at 11:59 PM, Stefan Hajnoczi wrote: > On Tue, Apr 11, 2017 at 08:05:12PM +0800, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default, >> this maybe cause the qcow2

Re: [Qemu-devel] [Bug 1681688] Re: qemu live migration failed

Hi Kevin: Can you provide some information about the original bug which you want fix? the original comment: Usually guest devices don't like other writers to the same image, so they use blk_set_perm() to prevent this from happening. i don't find where the dest qemu will use

Re: [Qemu-devel] [Qemu-block] [PATCH v3] migration/block:limit the time used for block migration

On Tue, Apr 11, 2017 at 8:19 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Mon, Apr 10, 2017 at 9:52 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Sat, Apr 08, 2017 at 09:17:58PM +0800, 858585 jemmy wrote: >>> On Fri, Apr 7, 2017 at 7:34 PM, Stefan

Re: [Qemu-devel] [Qemu-block] [PATCH v3] migration/block:limit the time used for block migration

On Mon, Apr 10, 2017 at 9:52 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Sat, Apr 08, 2017 at 09:17:58PM +0800, 858585 jemmy wrote: >> On Fri, Apr 7, 2017 at 7:34 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: >> > On Fri, Apr 07, 2017 at 09:30:

Re: [Qemu-devel] [PATCH v3] migration/block: use blk_pwrite_zeroes for each zero cluster

On Tue, Apr 11, 2017 at 12:00 AM, Stefan Hajnoczi wrote: > On Sun, Apr 09, 2017 at 08:37:40PM +0800, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default, >> this maybe cause the qcow2

Re: [Qemu-devel] [Bug 1662050] Re: qemu-img convert a overlay qcow2 image into a entire image

On Mon, Apr 10, 2017 at 1:07 PM, wayen <1662...@bugs.launchpad.net> wrote: > Hi Lidong Chen: > I used QEMU 2.0.0 on Ubuntu 14.04. > Do you mean your patch can make qemu-img convert qcow2 overlay into a new > overlay? yes. but i find it already fixed in 2.0.0. do you add the -o

Re: [Qemu-devel] [Bug 1662050] Re: qemu-img convert a overlay qcow2 image into a entire image

Hi wayen: Which version are you used? I also find this problem on old version qemu, and i write a patch for it. It works. I'm not sure the mainline version have solve this problem. what command are you used? On Mon, Apr 10, 2017 at 10:14 AM, wayen <1662...@bugs.launchpad.net>

Re: [Qemu-devel] [PATCH v2] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 10, 2017 at 9:47 AM, Fam Zheng <f...@redhat.com> wrote: > On Sat, 04/08 21:29, 858585 jemmy wrote: >> On Sat, Apr 8, 2017 at 12:52 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: >> > On Fri, Apr 7, 2017 at 6:10 PM, Fam Zheng <f...@redhat.com> wrote:

Re: [Qemu-devel] [PATCH v3] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 10, 2017 at 8:51 AM, Fam Zheng wrote: > On Sun, 04/09 20:37, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default, >> this maybe cause the qcow2 file size is bigger after

Re: [Qemu-devel] [PATCH v3] migration/block:limit the time used for block migration

On Fri, Apr 7, 2017 at 7:33 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > On Fri, Apr 07, 2017 at 09:30:33AM +0800, 858585 jemmy wrote: >> On Thu, Apr 6, 2017 at 10:02 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: >> > On Wed, Apr 05, 2017 at 05:27:58PM +080

Re: [Qemu-devel] [PATCH v2] migration/block: use blk_pwrite_zeroes for each zero cluster

On Sat, Apr 8, 2017 at 12:52 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Fri, Apr 7, 2017 at 6:10 PM, Fam Zheng <f...@redhat.com> wrote: >> On Fri, 04/07 16:44, jemmy858...@gmail.com wrote: >>> From: Lidong Chen <lidongc...@tencent.com> >>> &g

Re: [Qemu-devel] [PATCH v3] migration/block:limit the time used for block migration

On Fri, Apr 7, 2017 at 7:34 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > On Fri, Apr 07, 2017 at 09:30:33AM +0800, 858585 jemmy wrote: >> On Thu, Apr 6, 2017 at 10:02 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: >> > On Wed, Apr 05, 2017 at 05:27:58PM +080

Re: [Qemu-devel] [PATCH v2] migration/block: use blk_pwrite_zeroes for each zero cluster

On Fri, Apr 7, 2017 at 6:10 PM, Fam Zheng wrote: > On Fri, 04/07 16:44, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default, >> this maybe cause the qcow2 file size is bigger after

Re: [Qemu-devel] [PATCH v3] migration/block:limit the time used for block migration

On Fri, Apr 7, 2017 at 9:30 AM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Thu, Apr 6, 2017 at 10:02 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: >> On Wed, Apr 05, 2017 at 05:27:58PM +0800, jemmy858...@gmail.com wrote: >>> From: Lidong Chen <lid

Re: [Qemu-devel] [PATCH 2/2] migration/block: use blk_pwrite_zeroes for each zero cluster

On Fri, Apr 7, 2017 at 3:08 PM, Fam Zheng wrote: > On Thu, 04/06 21:15, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default, >> this maybe cause the qcow2 file size is bigger after

Re: [Qemu-devel] [PATCH 0/2] use blk_pwrite_zeroes for each zero cluster

On Fri, Apr 7, 2017 at 1:22 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > the test result for this patch: > > the migration command : > virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 > --copy-storage-all qemu+ssh://10.59.163.38/system > > the qemu-img info

Re: [Qemu-devel] [PATCH 0/2] use blk_pwrite_zeroes for each zero cluster

the test result for this patch: the migration command : virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 --copy-storage-all qemu+ssh://10.59.163.38/system the qemu-img info on source host: qemu-img info

Re: [Qemu-devel] [PATCH v3] migration/block:limit the time used for block migration

On Thu, Apr 6, 2017 at 10:02 PM, Stefan Hajnoczi wrote: > On Wed, Apr 05, 2017 at 05:27:58PM +0800, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> when migration with high speed, mig_save_device_bulk invoke >> bdrv_is_allocated too

Re: [Qemu-devel] [PATCH v3] migration/block:limit the time used for block migration

On Wed, Apr 5, 2017 at 6:44 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Wed, Apr 5, 2017 at 5:34 PM, Daniel P. Berrange <berra...@redhat.com> > wrote: >> On Wed, Apr 05, 2017 at 05:27:58PM +0800, jemmy858...@gmail.com wrote: >>> From: Lidong Chen <

Re: [Qemu-devel] [PATCH v3] migration/block:limit the time used for block migration

On Wed, Apr 5, 2017 at 5:34 PM, Daniel P. Berrange wrote: > On Wed, Apr 05, 2017 at 05:27:58PM +0800, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> when migration with high speed, mig_save_device_bulk invoke >> bdrv_is_allocated too

Re: [Qemu-devel] [PATCH v2] migration/block:limit the time used for block migration

sorry, i make a mistake, ignore this patch. On Wed, Apr 5, 2017 at 4:58 PM, wrote: > From: Lidong Chen > > when migration with quick speed, mig_save_device_bulk invoke > bdrv_is_allocated too frequently, and cause vnc reponse slowly. > this patch

Re: [Qemu-devel] [RFC] migration/block:limit the time used for block migration

On Wed, Mar 29, 2017 at 9:21 PM, 858585 jemmy <jemmy858...@gmail.com> wrote: > On Tue, Mar 28, 2017 at 5:47 PM, Juan Quintela <quint...@redhat.com> wrote: >> Lidong Chen <jemmy858...@gmail.com> wrote: >>> when migration with quick speed, mig_save_device_b

Re: [Qemu-devel] [RFC] migration/block:limit the time used for block migration

On Wed, Mar 29, 2017 at 11:57 PM, Juan Quintela <quint...@redhat.com> wrote: > > 858585 jemmy <jemmy858...@gmail.com> wrote: > > On Tue, Mar 28, 2017 at 5:47 PM, Juan Quintela <quint...@redhat.com> wrote: > >> Lidong Chen <jemmy858...@gmail.com>

Re: [Qemu-devel] [RFC] migration/block:limit the time used for block migration

On Tue, Mar 28, 2017 at 5:47 PM, Juan Quintela wrote: > Lidong Chen wrote: >> when migration with quick speed, mig_save_device_bulk invoke >> bdrv_is_allocated too frequently, and cause vnc reponse slowly. >> this patch limit the time used for

Re: [Qemu-devel] [RFC] migration/block:limit the time used for block migration

when migrate the vm with quick speed, i find vnc response slowly. the bug can be reproduce by this command: virsh migrate-setspeed 165cf436-312f-47e7-90f2-f8aa63f34893 900 virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 --copy-storage-inc qemu+ssh://10.59.163.38/system and

Re: [Qemu-devel] [PATCH] migration/block: Avoid involve into blk_drain too frequently

On Wed, Mar 15, 2017 at 10:57 AM, Fam Zheng <f...@redhat.com> wrote: > On Wed, 03/15 10:28, 858585 jemmy wrote: >> On Tue, Mar 14, 2017 at 11:12 PM, Eric Blake <ebl...@redhat.com> wrote: >> > On 03/14/2017 02:57 AM, jemmy858...@gmail.com wrote: >> >>

  1   2   >