From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43785C32750 for ; Tue, 13 Aug 2019 16:31:18 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 125C320679 for ; Tue, 13 Aug 2019 16:31:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 125C320679 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxZhd-0000dU-Bu for qemu-devel@archiver.kernel.org; Tue, 13 Aug 2019 12:31:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58219) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxZgx-0008WN-Jx for qemu-devel@nongnu.org; Tue, 13 Aug 2019 12:30:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hxZgw-00048g-Gt for qemu-devel@nongnu.org; Tue, 13 Aug 2019 12:30:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16685) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hxZgu-00046L-11; Tue, 13 Aug 2019 12:30:32 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8B805316D8C2; Tue, 13 Aug 2019 16:30:30 +0000 (UTC) Received: from dresden.str.redhat.com (unknown [10.40.205.136]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 20C3082212; Tue, 13 Aug 2019 16:30:22 +0000 (UTC) To: Vladimir Sementsov-Ogievskiy , "qemu-block@nongnu.org" References: <20190810193155.58637-1-vsementsov@virtuozzo.com> <20190810193155.58637-7-vsementsov@virtuozzo.com> <5102eac9-125b-0719-910f-4adb240732f1@redhat.com> <89c87c83-276a-7663-a239-57dbd9f91a30@virtuozzo.com> <4093762b-a1bc-d6b1-8358-4f9d1ab52557@virtuozzo.com> <9b7a3060-4880-9ef4-89f2-e8327ce655b8@redhat.com> <9479f6b6-3cfe-8594-d8fc-9a66c8f799c1@virtuozzo.com> From: Max Reitz Openpgp: preference=signencrypt Autocrypt: addr=mreitz@redhat.com; prefer-encrypt=mutual; keydata= mQENBFXOJlcBCADEyyhOTsoa/2ujoTRAJj4MKA21dkxxELVj3cuILpLTmtachWj7QW+TVG8U /PsMCFbpwsQR7oEy8eHHZwuGQsNpEtNC2G/L8Yka0BIBzv7dEgrPzIu+W3anZXQW4702+uES U29G8TP/NGfXRRHGlbBIH9KNUnOSUD2vRtpOLXkWsV5CN6vQFYgQfFvmp5ZpPeUe6xNplu8V mcTw8OSEDW/ZnxJc8TekCKZSpdzYoxfzjm7xGmZqB18VFwgJZlIibt1HE0EB4w5GsD7x5ekh awIe3RwoZgZDLQMdOitJ1tUc8aqaxvgA4tz6J6st8D8pS//m1gAoYJWGwwIVj1DjTYLtABEB AAG0HU1heCBSZWl0eiA8bXJlaXR6QHJlZGhhdC5jb20+iQFTBBMBCAA9AhsDBQkSzAMABQsJ CAcCBhUICQoLAgQWAgMBAh4BAheABQJVzie5FRhoa3A6Ly9rZXlzLmdudXBnLm5ldAAKCRD0 B9sAYdXPQDcIB/9uNkbYEex1rHKz3mr12uxYMwLOOFY9fstP5aoVJQ1nWQVB6m2cfKGdcRe1 2/nFaHSNAzT0NnKz2MjhZVmcrpyd2Gp2QyISCfb1FbT82GMtXFj1wiHmPb3CixYmWGQUUh+I AvUqsevLA+WihgBUyaJq/vuDVM1/K9Un+w+Tz5vpeMidlIsTYhcsMhn0L9wlCjoucljvbDy/ 8C9L2DUdgi3XTa0ORKeflUhdL4gucWoAMrKX2nmPjBMKLgU7WLBc8AtV+84b9OWFML6NEyo4 4cP7cM/07VlJK53pqNg5cHtnWwjHcbpGkQvx6RUx6F1My3y52vM24rNUA3+ligVEgPYBuQEN BFXOJlcBCADAmcVUNTWT6yLWQHvxZ0o47KCP8OcLqD+67T0RCe6d0LP8GsWtrJdeDIQk+T+F xO7DolQPS6iQ6Ak2/lJaPX8L0BkEAiMuLCKFU6Bn3lFOkrQeKp3u05wCSV1iKnhg0UPji9V2 W5eNfy8F4ZQHpeGUGy+liGXlxqkeRVhLyevUqfU0WgNqAJpfhHSGpBgihUupmyUg7lfUPeRM DzAN1pIqoFuxnN+BRHdAecpsLcbR8sQddXmDg9BpSKozO/JyBmaS1RlquI8HERQoe6EynJhd 64aICHDfj61rp+/0jTIcevxIIAzW70IadoS/y3DVIkuhncgDBvGbF3aBtjrJVP+5ABEBAAGJ ASUEGAEIAA8FAlXOJlcCGwwFCRLMAwAACgkQ9AfbAGHVz0CbFwf9F/PXxQR9i4N0iipISYjU sxVdjJOM2TMut+ZZcQ6NSMvhZ0ogQxJ+iEQ5OjnIputKvPVd5U7WRh+4lF1lB/NQGrGZQ1ic alkj6ocscQyFwfib+xIe9w8TG1CVGkII7+TbS5pXHRxZH1niaRpoi/hYtgzkuOPp35jJyqT/ /ELbqQTDAWcqtJhzxKLE/ugcOMK520dJDeb6x2xVES+S5LXby0D4juZlvUj+1fwZu+7Io5+B bkhSVPb/QdOVTpnz7zWNyNw+OONo1aBUKkhq2UIByYXgORPFnbfMY7QWHcjpBVw9MgC4tGeF R4bv+1nAMMxKmb5VvQCExr0eFhJUAHAhVg== Message-ID: Date: Tue, 13 Aug 2019 18:30:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7Fpxdyq4TawZ0ZxyqIYTp2nH9L9NsCPju" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Tue, 13 Aug 2019 16:30:30 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH v3 6/7] block/backup: teach backup_cow_with_bounce_buffer to copy more at once X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "fam@euphon.net" , "kwolf@redhat.com" , Denis Lunev , "qemu-devel@nongnu.org" , "armbru@redhat.com" , "stefanha@redhat.com" , "jsnow@redhat.com" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7Fpxdyq4TawZ0ZxyqIYTp2nH9L9NsCPju Content-Type: multipart/mixed; boundary="Jcf8xhZziZbL5M2bTMe3kJZcuHqc9xsaa"; protected-headers="v1" From: Max Reitz To: Vladimir Sementsov-Ogievskiy , "qemu-block@nongnu.org" Cc: "qemu-devel@nongnu.org" , "armbru@redhat.com" , "fam@euphon.net" , "stefanha@redhat.com" , "kwolf@redhat.com" , "jsnow@redhat.com" , Denis Lunev Message-ID: Subject: Re: [PATCH v3 6/7] block/backup: teach backup_cow_with_bounce_buffer to copy more at once References: <20190810193155.58637-1-vsementsov@virtuozzo.com> <20190810193155.58637-7-vsementsov@virtuozzo.com> <5102eac9-125b-0719-910f-4adb240732f1@redhat.com> <89c87c83-276a-7663-a239-57dbd9f91a30@virtuozzo.com> <4093762b-a1bc-d6b1-8358-4f9d1ab52557@virtuozzo.com> <9b7a3060-4880-9ef4-89f2-e8327ce655b8@redhat.com> <9479f6b6-3cfe-8594-d8fc-9a66c8f799c1@virtuozzo.com> In-Reply-To: --Jcf8xhZziZbL5M2bTMe3kJZcuHqc9xsaa Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 13.08.19 17:32, Vladimir Sementsov-Ogievskiy wrote: > 13.08.2019 18:02, Max Reitz wrote: >> On 13.08.19 17:00, Vladimir Sementsov-Ogievskiy wrote: >>> 13.08.2019 17:57, Max Reitz wrote: >>>> On 13.08.19 16:39, Vladimir Sementsov-Ogievskiy wrote: >>>>> 13.08.2019 17:23, Max Reitz wrote: >>>>>> On 13.08.19 16:14, Vladimir Sementsov-Ogievskiy wrote: [...] >>>>>>> But still.. >>>>>>> >>>>>>> Synchronous mirror allocates full-request buffers on guest write.= Is it correct? >>>>>>> >>>>>>> If we assume that it is correct to double memory usage of guest o= perations, than for backup >>>>>>> the problem is only in write_zero and discard where guest-assumed= memory usage should be zero. >>>>>> >>>>>> Well, but that is the problem. I didn=E2=80=99t say anything in v= 2, because I >>>>>> only thought of normal writes and I found it fine to double the me= mory >>>>>> usage there (a guest won=E2=80=99t issue huge write requests in pa= rallel). But >>>>>> discard/write-zeroes are a different matter. >>>>>> >>>>>>> And if we should distinguish writes from write_zeroes and discard= , it's better to postpone this >>>>>>> improvement to be after backup-top filter merged. >>>>>> >>>>>> But do you need to distinguish it? Why not just keep track of mem= ory >>>>>> usage and put the current I/O coroutine to sleep in a CoQueue or >>>>>> something, and wake that up at the end of backup_do_cow()? >>>>>> >>>>> >>>>> 1. Because if we _can_ allow doubling of memory, it's more effectiv= e to not restrict allocations on >>>>> guest writes. It's just seems to be more effective technique. >>>> >>>> But the problem with backup and zero writes/discards is that the mem= ory >>>> is not doubled. The request doesn=E2=80=99t need any memory, but th= e CBW >>>> operation does, and maybe lots of it. >>>> >>>> So the guest may issue many zero writes/discards in parallel and thu= s >>>> exhaust memory on the host. >>> >>> So this is the reason to separate writes from write-zeros/discrads. S= o at least write will be happy. And I >>> think that write is more often request than write-zero/discard >> >> But that makes it complicated for no practical gain whatsoever. >> >>>> >>>>> 2. Anyway, I'd allow some always-available size to allocate - let i= t be one cluster, which will correspond >>>>> to current behavior and prevent guest io hang in worst case. >>>> >>>> The guest would only hang if it we have to copy more than e.g. 64 MB= at >>>> a time. At which point I think it=E2=80=99s not unreasonable to seq= uentialize >>>> requests. >> >> Because of this. How is it bad to start sequentializing writes when t= he >> data exceeds 64 MB? >> >=20 > So you want total memory limit of 64 MB? (with possible parameter like = in mirror) >=20 > And allocation algorithm to copy count bytes: >=20 > if free_mem >=3D count: allocate count bytes > else if free_mem >=3D cluster: allocate cluster and copy in a loop > else wait in co-queue until some memory available and retry >=20 > Is it OK for you? Sounds good to me, although I don=E2=80=99t know whether the second branc= h is necessary. As I=E2=80=99ve said, the total limit is just an insurance ag= ainst a guest that does some crazy stuff. Max --Jcf8xhZziZbL5M2bTMe3kJZcuHqc9xsaa-- --7Fpxdyq4TawZ0ZxyqIYTp2nH9L9NsCPju Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEkb62CjDbPohX0Rgp9AfbAGHVz0AFAl1S5Z0ACgkQ9AfbAGHV z0BLpAf/RstmFU2HJVkNKyfg/+MnDMeyePrM1s2x8YKh0QKO5PJk85nJhgclN37G 9Np3I1hMqYqCKDKG/N/j6d7x15SQvf3bzCMMMEG1FuqRjfzoIPwWH6/QCRJJXP1l lAXYu4C8ylNwD1UJTBIHwjtV3E+l+oiGeEOoKKoIC61e3Vlgm12EXw2LzxK2Be6g euOz2wr9ZYeIrpwHPr8aUCWz1ckwRYYQXUi0OOsyPGmR4SiND1kFLpnrHPxfBDg9 Rkf+LI9bV03D/uVQfGVNr8xV5BbCxNKUUknXbaa5YujM/RQsQ2relksIgucaIPG+ hytO/vBrVDY4AvVlTGFTCqScXUL84g== =gpW/ -----END PGP SIGNATURE----- --7Fpxdyq4TawZ0ZxyqIYTp2nH9L9NsCPju--