From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kai Huang Subject: Re: [PATCH 3/6] KVM: Dirty memory tracking for performant checkpointing and improved live migration Date: Fri, 06 May 2016 21:46:03 +1200 Message-ID: <1462527963.5845.0@smtp.gmail.com> References: <33d8668e-2bba-af91-069e-6452609a6ff0@linux.intel.com> <20160429181911.GA2687@potion> <20160503141118.GA27975@potion> <32d8060e-648c-cf99-970a-3ddadc6a501a@linux.intel.com> <20160504131314.GA27590@potion> <20160504185734.GC27590@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Cao, Lei" , "Huang, Kai" , Paolo Bonzini , "kvm@vger.kernel.org" To: Radim =?iso-8859-2?b?S3LobeH4?= Return-path: Received: from mail-pa0-f65.google.com ([209.85.220.65]:34434 "EHLO mail-pa0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751511AbcEFJqP convert rfc822-to-8bit (ORCPT ); Fri, 6 May 2016 05:46:15 -0400 Received: by mail-pa0-f65.google.com with SMTP id yl2so10106235pac.1 for ; Fri, 06 May 2016 02:46:15 -0700 (PDT) In-Reply-To: <20160504185734.GC27590@potion> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, May 5, 2016 at 6:57 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 =20 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,= =20 >>> so why use >>> radix tree with added complexity but no benefit? >>>=20 >>> List can be designed to be lockless, so memslot -> lockless fixed=20 >>> list? >>=20 >> Never mind, lookup is needed to avoid duplicates. We can use=20 >> 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=20 > few > duplicates, depending on how dirtying and vm-exit on write to clean=20 > page > cooperate. Duplicates don't introduce any bugs and we could also=20 > check > last few entries in the list to weed out most likely cases.) I don't think duplicated pages are significant problem. The point is we= =20 don't lose pages. I actually don't quite follow why there will be duplicated pages. Is it= =20 because lockless thing? Thanks, -Kai >=20 > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html