From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNXys-0003DG-I3 for qemu-devel@nongnu.org; Thu, 06 Aug 2015 23:06:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNXyo-0005pl-C4 for qemu-devel@nongnu.org; Thu, 06 Aug 2015 23:06:02 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:31119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNXyn-0005nz-Of for qemu-devel@nongnu.org; Thu, 06 Aug 2015 23:05:58 -0400 References: <1434450415-11339-1-git-send-email-dgilbert@redhat.com> <1434450415-11339-42-git-send-email-dgilbert@redhat.com> <87zj2yepcq.fsf@neno.neno> <20150728060214.GJ12267@grmbl.mre> <87egjstt47.fsf@neno.neno> <20150806145506.GG2251@work-vm> From: zhanghailiang Message-ID: <55C4207A.6080308@huawei.com> Date: Fri, 7 Aug 2015 11:05:30 +0800 MIME-Version: 1.0 In-Reply-To: <20150806145506.GG2251@work-vm> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 41/42] Disable mlock around incoming postcopy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , Juan Quintela Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, liang.z.li@intel.com, peter.huangpeng@huawei.com, qemu-devel@nongnu.org, luis@cs.umu.se, Amit Shah , pbonzini@redhat.com, david@gibson.dropbear.id.au On 2015/8/6 22:55, Dr. David Alan Gilbert wrote: > * Juan Quintela (quintela@redhat.com) wrote: >> Amit Shah wrote: >>> On (Tue) 14 Jul 2015 [17:22:13], Juan Quintela wrote: >>>> "Dr. David Alan Gilbert (git)" wrote: >>> >>>>> + if (enable_mlock) { >>>>> + if (os_mlock() < 0) { >>>>> + error_report("mlock: %s", strerror(errno)); >>>>> + /* >>>>> + * It doesn't feel right to fail at this point, we have a valid >>>>> + * VM state. >>>>> + */ >>>> >>>> realtime_init() exit in case of os_mlock() fails, so current code is: >>> >>> Yea, I was wondering the same - but then I thought: would the realtime >>> case want a migration to happen at all? >> >> Then disable migration with realtime looks like saner. But that >> decission don't belong to this series. > > I added this patch because Zhanghailiang had reported trying to use it and it > failing. > > Zhanghailiang: Do you have a use case for mlock=on and migration? > Yes, we usually configure mlock=on for VM that needs high performance, and we also support migration for these VMs. It works well for pre-copy migration with this configuration. IMHO, it is better to support this for post-copy migration too~ (Or maybe we could add dynamically mlock/munlock memory command for qemu, and let management layer to decide what to do if they want to post-copy VM with mlocking memory ?). >> >>> >>>> - we start qemu with mlock requset >>>> - we mlock memory >>>> - we start postcopy >>>> - we munlock memory >>>> - we mlock memory >>>> >>>> I wmill really, really preffer having a check if memory is mlocked, and >>>> it that case, just abort migration altogether. Or better still, wait to >>>> enable mlock *until* we have finished postcopy, no? >>> >>> Amit > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > . >