From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCnrU-0006Hg-Cw for qemu-devel@nongnu.org; Thu, 31 Jul 2014 06:45:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCnrO-0001pN-6l for qemu-devel@nongnu.org; Thu, 31 Jul 2014 06:45:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCnrN-0001p9-Vt for qemu-devel@nongnu.org; Thu, 31 Jul 2014 06:45:22 -0400 Message-ID: <53DA1E32.4060901@redhat.com> Date: Thu, 31 Jul 2014 12:45:06 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1406720388-18671-1-git-send-email-ming.lei@canonical.com> <1406720388-18671-2-git-send-email-ming.lei@canonical.com> <53D8F6F0.7040106@redhat.com> <53D981C0.4030708@redhat.com> <20140731073700.GB707@irqsave.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/15] qemu coroutine: support bypass mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ming Lei , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= Cc: Kevin Wolf , Peter Maydell , Fam Zheng , "Michael S. Tsirkin" , qemu-devel , Stefan Hajnoczi Il 31/07/2014 11:47, Ming Lei ha scritto: >> Block mirroring of a device for example is done using coroutines. >> As block mirroring can be done on a raw device you need coroutines. > > If block layer knows the mirroring is in-progress, it still can enable > coroutine by ignoring bypass coroutine, or just let device disable > bypass coroutine in case of mirroring, and the current APIs are very > flexible. What matters is not whether you're mirroring. What matters is whether you're calling bdrv_aio_readv/writev or bdrv_co_readv/writev. Under some limitation, if you are calling bdrv_aio_readv/writev you can bypass coroutines. (In fact drive mirroring uses those APIs too so it doesn't need coroutines and can benefit from the speedup too. :) But drive-backup does need them). The limitations are essentially "would bdrv_co_do_preadv or bdrv_co_do_pwritev do anything special?" This means for example for bdrv_co_do_pwritev: - bs->drv must be non-NULL - bs->read_only must be false - bdrv_check_byte_request(bs, offset, bytes) must return false - bs->io_limits_enabled must be false - the request must be aligned - (in bdrv_aligned_pwritev) the before_write_notifiers must be empty - (in bdrv_aligned_pwritev) bs->detect_zeroes must be off - (in bdrv_aligned_pwritev) the BDRV_REQ_ZERO_WRITE flag must be off - (in bdrv_aligned_pwritev) bs->enable_write_cache must be false and the hard part is organizing the code so that the code duplication is as limited as possible. Paolo