From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH 3/6] KVM: Dirty memory tracking for performant checkpointing and improved live migration Date: Fri, 6 May 2016 14:09:09 +0200 Message-ID: <20160506120909.GK30059@potion> References: <20160429181911.GA2687@potion> <20160503141118.GA27975@potion> <32d8060e-648c-cf99-970a-3ddadc6a501a@linux.intel.com> <20160504131314.GA27590@potion> <20160504185734.GC27590@potion> <1462527963.5845.0@smtp.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Cao, Lei" , "Huang, Kai" , Paolo Bonzini , "kvm@vger.kernel.org" To: Kai Huang Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51636 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758083AbcEFMJO (ORCPT ); Fri, 6 May 2016 08:09:14 -0400 Content-Disposition: inline In-Reply-To: <1462527963.5845.0@smtp.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: 2016-05-06 21:46+1200, Kai Huang: > On Thu, May 5, 2016 at 6:57 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> 2016-05-04 18:33+0000, Cao, Lei: >> > On 5/4/2016 1:15 PM, Cao, Lei wrote: >> > > On 5/4/2016 9:13 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> > > > Good designs so far seem to be: >> > > > memslot -> lockless radix tree >> > > > and >> > > > vcpu -> memslot -> list (memslot -> vcpu -> list) >> > > >=20 >> > >=20 >> > > There is no need for lookup, the dirty log is fetched in >> > > sequence, so why use >> > > radix tree with added complexity but no benefit? >> > >=20 >> > > List can be designed to be lockless, so memslot -> lockless >> > > fixed list? >> >=20 >> > Never mind, lookup is needed to avoid duplicates. We can use >> > list+bitmap, but >> > it's obviously not as efficient as radix tree. >>=20 >> Are duplicates a significant problem? >>=20 >> (The dirtied page is marked as dirty, so we should have zero to very= few >> duplicates, depending on how dirtying and vm-exit on write to clean >> page >> cooperate. Duplicates don't introduce any bugs and we could also c= heck >> last few entries in the list to weed out most likely cases.) >=20 > I don't think duplicated pages are significant problem. The point is = we > don't lose pages. >=20 > I actually don't quite follow why there will be duplicated pages. Is = it > because lockless thing? Not really. The ugly bitmap to avoid duplicates in this series makes m= e think that hardware does force an exit on multiple VCPUs if they concurrently write to the same clear page. A list, or any per-vcpu structure, will have multiple dirty entries if that happens.