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: Sat, 7 May 2016 13:48:03 +1200 Message-ID: <572D4953.30108@gmail.com> 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> <20160506120909.GK30059@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: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from mail-pa0-f66.google.com ([209.85.220.66]:34921 "EHLO mail-pa0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758900AbcEGBsJ (ORCPT ); Fri, 6 May 2016 21:48:09 -0400 Received: by mail-pa0-f66.google.com with SMTP id zy2so13492108pac.2 for ; Fri, 06 May 2016 18:48:08 -0700 (PDT) In-Reply-To: <20160506120909.GK30059@potion> Sender: kvm-owner@vger.kernel.org List-ID: On 05/07/2016 12:09 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 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) >>>>>> >>>>> There is no need for lookup, the dirty log is fetched in >>>>> sequence, so why use >>>>> radix tree with added complexity but no benefit? >>>>> >>>>> List can be designed to be lockless, so memslot -> lockless >>>>> fixed list? >>>> Never mind, lookup is needed to avoid duplicates. We can use >>>> list+bitmap, but >>>> it's obviously not as efficient as radix tree. >>> Are duplicates a significant problem? >>> >>> (The dirtied page is marked as dirty, so we should have zero to ver= y few >>> duplicates, depending on how dirtying and vm-exit on write to cle= an >>> page >>> cooperate. Duplicates don't introduce any bugs and we could also= 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 >> don't lose pages. >> >> 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= me > 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. Oh yes. This makes sense. This also counts a disadvantage of per-vcpu=20 structure. Thanks, -Kai