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 18:04:06 +0200 Message-ID: <20160506160405.GB31834@potion> References: <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 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Kai Huang , "Huang, Kai" , Paolo Bonzini , "kvm@vger.kernel.org" To: "Cao, Lei" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38934 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758274AbcEFQEK (ORCPT ); Fri, 6 May 2016 12:04:10 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2016-05-06 15:13+0000, Cao, Lei: > On 5/6/2016 8: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 ve= ry 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 i= s we >>> don't lose pages. >>> >>> I actually don't quite follow why there will be duplicated pages. I= s it >>> because lockless thing? >>=20 >> Not really. The ugly bitmap to avoid duplicates in this series make= s 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. >>=20 >=20 > We do see tons of duplicates. Majority are from kvm updating guest ti= me, > steal time, and setting/clearing PV EOI. >=20 > Duplicates don't introduce bugs, but are undesirable, given a fixed-s= ize > dirty log. Absolutely. I didn't realize there were this many duplicates and no method of filtering seems better than the bitmap. Looking forward to performance comparison with a tree! Thanks.