[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL715WLO9+CpNa4ZQX4J2OdyqOBsX0+g0M4bNe+A+6FVxB2OxA@mail.gmail.com>
Date: Mon, 9 Aug 2021 17:01:39 -0700
From: Mingwei Zhang <mizhang@...gle.com>
To: Jim Mattson <jmattson@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Joerg Roedel <joro@...tes.org>, kvm <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Ben Gardon <bgardon@...gle.com>,
David Matlack <dmatlack@...gle.com>,
Jing Zhang <jingzhangos@...gle.com>, peterx@...hat.com
Subject: Re: [PATCH v4 3/3] KVM: x86/mmu: Add detailed page size stats
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 <mizhang@...gle.com> 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 <jmattson@...gle.com> wrote:
> >
> > On Mon, Aug 2, 2021 at 9:46 PM Mingwei Zhang <mizhang@...gle.com> 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?
Powered by blists - more mailing lists