From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC05FC432BE for ; Tue, 10 Aug 2021 00:02:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C9A9360243 for ; Tue, 10 Aug 2021 00:02:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237094AbhHJACW (ORCPT ); Mon, 9 Aug 2021 20:02:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231127AbhHJACU (ORCPT ); Mon, 9 Aug 2021 20:02:20 -0400 Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4EEA5C0613D3 for ; Mon, 9 Aug 2021 17:01:51 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id w17so32764490ybl.11 for ; Mon, 09 Aug 2021 17:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u/6lDzTST0h+RyT6gU/s2Pzqgb7dbZvl8tVew71+7uA=; b=IXgv+KRKCsBVGj/yvVKxhDgYLPxGDqCg08pFEoQWD78TZ5q04i+NdqMAx4ATfGTjzw 4WGCqlwrSPFRgWpVrn/ib1PojT8GhH/z+vSzChsEuY1BT8qfkINf45tByHzSPvTPE/Kb lmO2FQsPz6b2XPf3GWv8n8RcxKrlWUIdh8Ok56CktrS6Kj4WpwpsvSirqvi7QTzgx6dA KeXmPH9pdNz7lJPYPZUDAZvWBlqFohqgIg2+VRL4ZnuNZKFQ/c07903n/OxOSVjnMG+M SLUORF78yEpLGIKTTDGYqHyjyR5g9EgR7T8uJGbnVrOIu+TESiS+rTqcn4HncxJwXEg7 mbFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u/6lDzTST0h+RyT6gU/s2Pzqgb7dbZvl8tVew71+7uA=; b=Ifr0f6V+3bAkYpZpLpvb2nevUTwa163jeQbHRxzLjYc9HxlDOYm5loejKHZRoB5uPW rVor3XIxU5AyPA/8IngT0jE06ytNIWiV8XmyzkBCPLtIISUH2jSmsaEBUIiRtxNeEOeg laWM9XGkxmaf+ao29CHZDGxG+OcaJTRMwWuQ4FCnXRihLbJsylkMG+CiYBjoMLimAZTT aYJ6KP3XSNBI6O54U/27pd+YE3Cu93Yhfa+r5uK5pYjb9gZP6fPzIw6wYHlF7RuHP7Ah fOO0UPzjXtlij5GmvV1RiWDwQ2VIG379kejDcc4cIb2H+IyZlDu7DdyuPM7dc6eodqih 1w4Q== X-Gm-Message-State: AOAM5314xFr4TG5xlY9HvWsZt1L8tHiexcfkRyKwgSA1z7OFJHMrQs68 DkL3pIVvPrSDS4iTiXDV9q2/yGw8VP4ZlnbWi5vXyA== X-Google-Smtp-Source: ABdhPJwanymbJHXSzhVU3ouc2r4BMfkwlf0QQ5JwTtfL17PzN357+PpyPsNiUZT/wN15PZ4CaB5DKmXx7A8TZqps84M= X-Received: by 2002:a25:dcd1:: with SMTP id y200mr33427728ybe.92.1628553710295; Mon, 09 Aug 2021 17:01:50 -0700 (PDT) MIME-Version: 1.0 References: <20210803044607.599629-1-mizhang@google.com> <20210803044607.599629-4-mizhang@google.com> In-Reply-To: From: Mingwei Zhang Date: Mon, 9 Aug 2021 17:01:39 -0700 Message-ID: Subject: Re: [PATCH v4 3/3] KVM: x86/mmu: Add detailed page size stats To: Jim Mattson Cc: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm , LKML , Ben Gardon , David Matlack , Jing Zhang , peterx@redhat.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paolo, I recently looked at the patches queued and I find this patch from Peter Xu (Cced), which is also adding 'page stats' information into KVM: https://patchwork.kernel.org/project/kvm/patch/20210625153214.43106-7-peterx@redhat.com/ >From a functionality point of view, the above patch seems duplicate with mine. But in detail, Peter's approach is using debugfs with proper locking to traverse the whole rmap to get the detailed page sizes in different granularity. In comparison, mine is to add extra code in low level SPTE update routines and store aggregated data in kvm->kvm_stats. This data could be retrieved from Jing's fd based API without any lock required, but it does not provide the fine granular information such as the number of contiguous 4KG/2MB/1GB pages. So would you mind giving me some feedback on this patch? I would really appreciate it. Thank you. Regards -Mingwei -Mingwei On Mon, Aug 9, 2021 at 4:39 PM Mingwei Zhang wrote: > > Hi Jim, > > No, I don't think 512G is supported. So, I will remove the > 'pages_512G' metric in my next version. > > Thanks. > -Mingwei > > On Mon, Aug 9, 2021 at 3:26 PM Jim Mattson wrote: > > > > On Mon, Aug 2, 2021 at 9:46 PM Mingwei Zhang wrote: > > > > > > Existing KVM code tracks the number of large pages regardless of their > > > sizes. Therefore, when large page of 1GB (or larger) is adopted, the > > > information becomes less useful because lpages counts a mix of 1G and 2M > > > pages. > > > > > > So remove the lpages since it is easy for user space to aggregate the info. > > > Instead, provide a comprehensive page stats of all sizes from 4K to 512G. > > > > There is no such thing as a 512GiB page, is there? If this is an > > attempt at future-proofing, why not go to 256TiB?