From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfPsQ-0001D5-Ks for qemu-devel@nongnu.org; Fri, 25 Sep 2015 06:05:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZfPsM-0007tP-7w for qemu-devel@nongnu.org; Fri, 25 Sep 2015 06:05:14 -0400 Received: from mx2.parallels.com ([199.115.105.18]:37701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfPsM-0007s0-1E for qemu-devel@nongnu.org; Fri, 25 Sep 2015 06:05:10 -0400 References: <56050489.9010306@cn.fujitsu.com> <1443172180-1005-1-git-send-email-den@openvz.org> <1443172180-1005-2-git-send-email-den@openvz.org> <560512B4.6020406@cn.fujitsu.com> <5605148F.7060305@openvz.org> <560515DC.8050004@cn.fujitsu.com> From: "Denis V. Lunev" Message-ID: <56051C4C.1020602@openvz.org> Date: Fri, 25 Sep 2015 13:05:00 +0300 MIME-Version: 1.0 In-Reply-To: <560515DC.8050004@cn.fujitsu.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] migration: bitmap_set is unnecessary as bitmap_new uses g_try_malloc0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Amit Shah , Igor Redko , Juan Quintela , qemu-devel@nongnu.org, Anna Melekhova On 09/25/2015 12:37 PM, Wen Congyang wrote: > On 09/25/2015 05:31 PM, Denis V. Lunev wrote: >> On 09/25/2015 12:24 PM, Wen Congyang wrote: >>> On 09/25/2015 05:09 PM, Denis V. Lunev wrote: >>>> we can omit calling of bitmap_set in migration_bitmap_extend and >>>> ram_save_setup just after bitmap_new, which properly zeroes memory >>>> inside. >>> This patch is wrong. bitmap_set() is set all bits of the memory to 1, >>> not 0. >>> >> OK, then I'll replace g_try_malloc0 with g_try_malloc in the next patch to avoid >> double memset > No, bitmap_new() is called in many places. Some caller needs zero memory, and > some caller doesn't need... > you are correct with your proposal with double allocation for the next patch. With a specific function like I have did in v2 g_try_malloc0 can be replaced. Anyway, I am fine with your proposal, this is not a (very) big deal. EINPROGRESS Den