Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2303597pxp; Mon, 21 Mar 2022 16:22:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzTepWEGA7aBGhmUwDKrNHvhACrNG21UvDikIAV0YkaTu/V7X/M9ZapyyUWZth9L+JsPtQ6 X-Received: by 2002:a65:63d6:0:b0:375:7cc6:2b63 with SMTP id n22-20020a6563d6000000b003757cc62b63mr19495431pgv.598.1647904968386; Mon, 21 Mar 2022 16:22:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647904968; cv=none; d=google.com; s=arc-20160816; b=Nv8pGB+Kpy0mFAZSHWF37rT1zGertLZWTKIKOCZZNEfd/dJypIYMiSkErXI2ZL1WKi mxXZb9xp7wNMcpI1KnQYxjzE1L+sl6hNbJ2m2ugK9MojtJm3VHtkf5A7FdtCvahjY/La OLaVYaF6C1rZZYjbg3wtowQL+e8+4Qmi+qN/1AN/62lMaSCBwvMUYe1sADOCu+W6a80x 19U6+5P005JQ4tOAr18Jix05xIlY8BNkprTlbHa/KPZPCq/yI/9y42n3C8/H1fgMapNe cuiqkoZTHX8MAsSixzu9QLVv/Ons6pEaSOsOXN75BE4E71ABea3s78Fv7u4N3L135yGS cBhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=k5w4N0h5znLSssiHLgmDMLO/EudzOjUrkLNNjZheWAI=; b=McPMaq43BWmqsAJJTtUroy+Cr2J1v0lXP83x4Xk4KfnzMPPU+W/HP1kvIcIiISohID vIXIfiuzCisqHV81It5tNLKeK3jeytUf/NORceM/pDET4hjB/TAftrZB55tRWr3AN7bO B/COgu5LiurOPbO7llSdiV3irIuccAgTy9pGq+G1NK3LiDUxaKRbHWR9Mrv4x0oxCG83 tdadWnjYbzQ26wYWncT0n4c289ScJK3Lp6/fDvf66OUm0ZTAI73zpYUUzm2aTrEjeXJg oGiZ+liiwVP24/0TIhOb0SN+D5LLM/aCDkQZDWlK1ceLy9wVhXrfqPGp0qZDYUmXLZzU kDyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=edwCAu21; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id t16-20020a17090ad51000b001c66aacdc00si572382pju.124.2022.03.21.16.22.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 16:22:48 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=edwCAu21; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5503F429676; Mon, 21 Mar 2022 15:23:23 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351882AbiCUR5h (ORCPT + 99 others); Mon, 21 Mar 2022 13:57:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351876AbiCUR5e (ORCPT ); Mon, 21 Mar 2022 13:57:34 -0400 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B85C4CD4D for ; Mon, 21 Mar 2022 10:56:08 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id g138so9050732ybf.5 for ; Mon, 21 Mar 2022 10:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k5w4N0h5znLSssiHLgmDMLO/EudzOjUrkLNNjZheWAI=; b=edwCAu21KDfzwfsUIjxupxnxd03VoHAyLXhHQyjvqBVhnTNuuUBnhzl3dEniVEm8aO Guj+kVOdz+kWhZ7OLAU+UlGILytgfK/lD6/L2C6bH9tiBpTT1xPU0QJsb1wrfnZJe9al UnguvPQ+7ir7phVa4D1FtxSMzn4gZnCFBomPGoNNF+2mnAwJJl3cEKvXjGL6XCDH2Olp ox3XrJfUyN4RhnLB9Zeb+RbaaZ3d0CvbRYL+pxgfj//VysIfyXA1OqrUCYQN6+yW6c7F q8Uz1v1nmmp5tzNp3/OZ81jJYyBrTcGHeKdFQxgaKL4xwxeWmIIXBePdrNtV/ejuP+M4 A5iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k5w4N0h5znLSssiHLgmDMLO/EudzOjUrkLNNjZheWAI=; b=GCuF1jH+BAQjEYOnyRmBD21Ia5HJZdXgse/g4J6/JhwILHQBguejQZ8OFvKWuSY53Z 7qUeI8t5tdHUwNv1vh3oU5/+UFROWxdjS+O/gwDru9Vq39yCL2ymjrNBP4DeOmlzkfeY O3T8hLFJsxH7Izd8KqcnEHCbWUOZuIPftbsADDi0qJr5TrqiC1UsX7bUEpStHUMTZQLb LcA7kYyOT++3XufxSy6M0m8cAivXb/F9Qy/zAQ7DbcXgytwlQPEXFWLgDWjZRuyDH28d I0dSFza4v+r1iFnPTlVsAFQt65VP+NAWz+Dwc3mk87M7UtEdpF2vySZPirGrJEBf0e2S SNMQ== X-Gm-Message-State: AOAM533bwcWYmjKp0lV9q5vhbeK8hsCyj6SYCcatfnhSObIRcmzmMjsu 8EXoSVM2Hu6s5k85POCDQLQyc5tctIWz8A1m7DEuiQ== X-Received: by 2002:a25:2449:0:b0:633:c9aa:b9de with SMTP id k70-20020a252449000000b00633c9aab9demr13464598ybk.255.1647885367378; Mon, 21 Mar 2022 10:56:07 -0700 (PDT) MIME-Version: 1.0 References: <20220321002638.379672-1-mizhang@google.com> <20220321002638.379672-5-mizhang@google.com> In-Reply-To: <20220321002638.379672-5-mizhang@google.com> From: Ben Gardon Date: Mon, 21 Mar 2022 10:55:56 -0700 Message-ID: Subject: Re: [PATCH 4/4] selftests: KVM: use dirty logging to check if page stats work correctly To: Mingwei Zhang Cc: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Matlack , Jing Zhang , Peter Xu , Ben Gardon Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 20, 2022 at 5:26 PM Mingwei Zhang wrote: > > When dirty logging is enabled, KVM splits the all hugepage mapping in > NPT/EPT into the smallest 4K size. This property could be used to check if Note this is only true if eager page splitting is enabled. It would be more accurate to say: "While dirty logging is enabled, KVM will re-map any accessed page in NPT/EPT at 4K." > the page stats metrics work properly in KVM mmu. At the same time, this > logic might be used the other way around: using page stats to verify if > dirty logging really splits all huge pages. Moreover, when dirty logging is It might be worth having a follow up commit which checks if eager splitting is enabled and changes the assertions accordingly. > disabled, KVM zaps corresponding SPTEs and we could check whether the large > pages come back when guest touches the pages again. > > So add page stats checking in dirty logging performance selftest. In > particular, add checks in three locations: > - just after vm is created; > - after populating memory into vm but before enabling dirty logging; > - just after turning on dirty logging. Note a key stage here is after dirty logging is enabled, and then the VM touches all the memory in the data region. I believe that's the point at which you're making the assertion that all mappings are 4k currently, which is the right place if eager splitting is not enabled. > - after one final iteration after turning off dirty logging. > > Tested using commands: > - ./dirty_log_perf_test -s anonymous_hugetlb_1gb > - ./dirty_log_perf_test -s anonymous_thp > > Cc: Sean Christopherson > Cc: David Matlack > Cc: Jing Zhang > Cc: Peter Xu > > Suggested-by: Ben Gardon > Signed-off-by: Mingwei Zhang > --- > .../selftests/kvm/dirty_log_perf_test.c | 52 +++++++++++++++++++ > 1 file changed, 52 insertions(+) > > diff --git a/tools/testing/selftests/kvm/dirty_log_perf_test.c b/tools/testing/selftests/kvm/dirty_log_perf_test.c > index 1954b964d1cf..ab0457d91658 100644 > --- a/tools/testing/selftests/kvm/dirty_log_perf_test.c > +++ b/tools/testing/selftests/kvm/dirty_log_perf_test.c > @@ -19,6 +19,10 @@ > #include "perf_test_util.h" > #include "guest_modes.h" > > +#ifdef __x86_64__ > +#include "processor.h" > +#endif > + > /* How many host loops to run by default (one KVM_GET_DIRTY_LOG for each loop)*/ > #define TEST_HOST_LOOP_N 2UL > > @@ -185,6 +189,14 @@ static void run_test(enum vm_guest_mode mode, void *arg) > p->slots, p->backing_src, > p->partition_vcpu_memory_access); > > +#ifdef __x86_64__ > + TEST_ASSERT(vm_get_single_stat(vm, "pages_4k") == 0, > + "4K page is non zero"); > + TEST_ASSERT(vm_get_single_stat(vm, "pages_2m") == 0, > + "2M page is non zero"); > + TEST_ASSERT(vm_get_single_stat(vm, "pages_1g") == 0, > + "1G page is non zero"); > +#endif > perf_test_set_wr_fract(vm, p->wr_fract); > > guest_num_pages = (nr_vcpus * guest_percpu_mem_size) >> vm_get_page_shift(vm); > @@ -222,6 +234,16 @@ static void run_test(enum vm_guest_mode mode, void *arg) > pr_info("Populate memory time: %ld.%.9lds\n", > ts_diff.tv_sec, ts_diff.tv_nsec); > > +#ifdef __x86_64__ > + TEST_ASSERT(vm_get_single_stat(vm, "pages_4k") != 0, > + "4K page is zero"); > + if (p->backing_src == VM_MEM_SRC_ANONYMOUS_THP) This should also handle 2M hugetlb memory. I think there might be a library function to translate backing src type to page size too, which could make this check cleaner. > + TEST_ASSERT(vm_get_single_stat(vm, "pages_2m") != 0, > + "2M page is zero"); > + if (p->backing_src == VM_MEM_SRC_ANONYMOUS_HUGETLB_1GB) > + TEST_ASSERT(vm_get_single_stat(vm, "pages_1g") != 0, > + "1G page is zero"); > +#endif > /* Enable dirty logging */ > clock_gettime(CLOCK_MONOTONIC, &start); > enable_dirty_logging(vm, p->slots); > @@ -267,6 +289,14 @@ static void run_test(enum vm_guest_mode mode, void *arg) > iteration, ts_diff.tv_sec, ts_diff.tv_nsec); > } > } > +#ifdef __x86_64__ > + TEST_ASSERT(vm_get_single_stat(vm, "pages_4k") != 0, > + "4K page is zero after dirty logging"); > + TEST_ASSERT(vm_get_single_stat(vm, "pages_2m") == 0, > + "2M page is non-zero after dirty logging"); > + TEST_ASSERT(vm_get_single_stat(vm, "pages_1g") == 0, > + "1G page is non-zero after dirty logging"); > +#endif Note this is after dirty logging has been enabled, AND all pages in the data region have been written by the guest. > > /* Disable dirty logging */ > clock_gettime(CLOCK_MONOTONIC, &start); > @@ -275,6 +305,28 @@ static void run_test(enum vm_guest_mode mode, void *arg) > pr_info("Disabling dirty logging time: %ld.%.9lds\n", > ts_diff.tv_sec, ts_diff.tv_nsec); > > +#ifdef __x86_64__ > + /* > + * Increment iteration to run the vcpus again to verify if huge pages > + * come back. > + */ > + iteration++; > + pr_info("Starting the final iteration to verify page stats\n"); > + > + for (vcpu_id = 0; vcpu_id < nr_vcpus; vcpu_id++) { > + while (READ_ONCE(vcpu_last_completed_iteration[vcpu_id]) > + != iteration) > + ; > + } We might as well do this on all archs. Even without the stats, it at least validates that disabling dirty logging doesn't break the VM. > + > + if (p->backing_src == VM_MEM_SRC_ANONYMOUS_THP) > + TEST_ASSERT(vm_get_single_stat(vm, "pages_2m") != 0, > + "2M page is zero"); > + if (p->backing_src == VM_MEM_SRC_ANONYMOUS_HUGETLB_1GB) > + TEST_ASSERT(vm_get_single_stat(vm, "pages_1g") != 0, > + "1G page is zero"); > +#endif > + > /* Tell the vcpu thread to quit */ > host_quit = true; > perf_test_join_vcpu_threads(nr_vcpus); > -- > 2.35.1.894.gb6a874cedc-goog >