On 5/6/2016 8:09 AM, Radim Krčmář wrote: > 2016-05-06 21:46+1200, Kai Huang: >> On Thu, May 5, 2016 at 6:57 AM, Radim Krčmář <rkrcmar@xxxxxxxxxx> 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čmář 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 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 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. > We do see tons of duplicates. Majority are from kvm updating guest time, steal time, and setting/clearing PV EOI. Duplicates don't introduce bugs, but are undesirable, given a fixed-size dirty log. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
