Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3256214pxt; Mon, 9 Aug 2021 22:15:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtIW3YRiGD5vYdrowVpAWng4u6xIGxV9CQQ9CzmD5lOBo1zZnqAeE+yAfZYL6sqGnO1QqY X-Received: by 2002:a92:dd0a:: with SMTP id n10mr194268ilm.301.1628572530997; Mon, 09 Aug 2021 22:15:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628572530; cv=none; d=google.com; s=arc-20160816; b=F3q0nfVch4OxKeAxgYO1CbtJCIVT0dAgYGs8Gi0OxHNeLhas1er5npAulMVbdHXYNt k4LVsH9Y8D5OaQRsCR01TqMzb/euI61xuB+nD6Z8PNbLs7mQ3CaS0g1ZRby5M1+rXYLd iFBLYJSVjsYASEwk1n6Aufw6/UKubY/eEbk09yMHu7V8q2UXgOy4nhvGxA3bdvCcpZK7 nilkt92fiN48sqjG+UTYZ9DHaQ/9aOPPKXRSsPRYKMhHOQdcqDBTTWRoaEFyflyuwGNh NbkP6Wp44e6s95WjxyZs+xwQHNpvLPFqpdxYVgR0B3wlx+EZy0oIw2EUIke34yZTecuA iQ3A== 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=u/6lDzTST0h+RyT6gU/s2Pzqgb7dbZvl8tVew71+7uA=; b=BoG8gIiPzdHwHw67gj19LASC51v/4nRQatQcCGv/S++Y0M1nbyWhOHb5v4rL+2qrpx gG23OAGrteWBGxaMTNHQBbPvgVzxs3gg7GkShyoMptynQrOOM5ZDK0N8+DFHH6H9lfs6 x4R1brOVE4rl03oH/SxJMf4iBMC2wo4oAI+sokbuFeZ54VWaOs25GryslU0ftr78X6xb jSJQOKlaHqKqlXyGevIYIoCtJBbWwhxAGwdEEMjM7I/YcclcNhy7zvHDm4VqYXJc2EmE Sb40chwT3zEmW034u7FT47ModhruQUwsixJ7q98Pt9gNk9HWplREa+lYwXuOBNwp//8J TCKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IXgv+KRK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q14si219954ioh.24.2021.08.09.22.14.59; Mon, 09 Aug 2021 22:15:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IXgv+KRK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237091AbhHJACV (ORCPT + 99 others); Mon, 9 Aug 2021 20:02:21 -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-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?