Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3974484pxt; Tue, 10 Aug 2021 16:24:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfvtrXsyVrVzm6VQGC6aaSVFoJ78LpxPoxIq1lSD3ixCWY34pc9dJMCrjkY0qqTb4+otJC X-Received: by 2002:a92:db4b:: with SMTP id w11mr54883ilq.297.1628637847977; Tue, 10 Aug 2021 16:24:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628637847; cv=none; d=google.com; s=arc-20160816; b=FOxfoAzNrlHxTSHZOEr7XbnIn7otDZfWG1TJblriL136zxl5Onki5+WzJqNlV27uH3 xLjgVKjOLT88sr5/fERMAUlyzDPrz7rEtx51Rt6gKL6lxgy2gcTsEAIQ+Ia+bh0C6Icj gh/SJxcZ9dHXf6bAdT598JX0VkrBQdf6+I3PKpDpME7D46HAsZA814o6i8X4lVYsOVp0 J3Tx6i5DH3UgVdR9UHiZ7l3ymV1JJKdyrS9ZAEEcT4po/AAP+JpuGX0kH6omvudAiCfK x4X8V2v7QoxXu//nBr/4CRbpWppVDqhO7dKTbtBCZQTvGBoNWaqfzsZan8S6nUKRLKah ZtTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=zebpogOe1quBLKE4Uo3idNxbcVJ3dkkOF+OjhdeOFhQ=; b=eMf1k5ju7q+7VXn5/GtsH/viNEn39DONYxf/Jqg46oJI9sh1wYrXeTILK2MeYUiTs0 E/xrbHKvEyMkDxWT58a618AYQ+CJiTsmJ2Y2WlzD73UC0qp2IMXIwjB5ZWQW/MP2GKfn c2NGJ+EnhyreV63wDl/K1WalpeZmNU5UI7R51eoNPW1wy0fDJ1oWwqwznlcFD1SrKDk3 I1moX/ufxfLfouBy2C6Wxz1fO3IGE4EhOxa9iIjReb0i2AKhbcbgYgygd1/9ydJRgjwz ra6Nh0cseaoezcXfwxYg1ZcIrRC7OU1Gcbqjq2bF3ZmaBWW55fKjxAEyiJIFH541Bowx 9svQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FJV3Enk9; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z23si21976075jap.22.2021.08.10.16.23.56; Tue, 10 Aug 2021 16:24:07 -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=@redhat.com header.s=mimecast20190719 header.b=FJV3Enk9; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235319AbhHJXXG (ORCPT + 99 others); Tue, 10 Aug 2021 19:23:06 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:44671 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235242AbhHJXXG (ORCPT ); Tue, 10 Aug 2021 19:23:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628637762; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zebpogOe1quBLKE4Uo3idNxbcVJ3dkkOF+OjhdeOFhQ=; b=FJV3Enk97eLoVlCtxOazQGI2hPVz2Xvfl4Ymd65Nv75CEGMgNAIoRz6c7mjPvjZ2nY7vNg P3zhyex+KCRPMWvTMLFVcCm0Tb4TCXjnntBeB/DNYwzT1vQfaQVFmgbYcGzyLOR0Y7YL7B hw3D2tPYHpRsRYuzQmETGvBgI9DB/lU= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-327-8sUeBw2HMiS1znibykBByA-1; Tue, 10 Aug 2021 19:22:40 -0400 X-MC-Unique: 8sUeBw2HMiS1znibykBByA-1 Received: by mail-qt1-f200.google.com with SMTP id w11-20020ac857cb0000b029024e7e455d67so321340qta.16 for ; Tue, 10 Aug 2021 16:22:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zebpogOe1quBLKE4Uo3idNxbcVJ3dkkOF+OjhdeOFhQ=; b=PdBviySRWf2lRXZsvfVDP66fodQ82UvLK2tSL07LF/9KdVmooJ8X2Cm6pmsUk9Khtr e/wMfukeZohPb23DlyNQfMdSvR02Vg36WfcK6BbUBZWm+fjjwQCVbEkS5f9oAEmqVeJi Ycm2D9vDQME3RcmYCVHIDTTmpUCAb/P2PGH9lsgG1Nu15GEeNgvU+zd9BJaWXIY7yY+4 MdBBjAj04W6bfz3WeAbfQpVrtKx6CBsEFJYo8j82vwuuNyk+B0v7E4XYP79oEZMz2Ved 0A8EBKcqqZN+CO393e8k1atXF4/MgnYlfTOYBmK/DxAKC+sirXgr52H17M5OJTzVjNzQ BSqw== X-Gm-Message-State: AOAM530qR+uHA91WQU/58l7JyGjvKUoQREsI6BFtNB1GqYAP0g7Mh7GH Eo9ILGYOrbObWylWbhmdI4/Of3dDk9VSjuMYkUFReaeKThZdcYNOJH4j1dsfmIBb8Z6F18EyKWB V4QLLbLaVLulyUz7HJPCrfyPZ X-Received: by 2002:a05:620a:318b:: with SMTP id bi11mr17242552qkb.302.1628637759724; Tue, 10 Aug 2021 16:22:39 -0700 (PDT) X-Received: by 2002:a05:620a:318b:: with SMTP id bi11mr17242527qkb.302.1628637759517; Tue, 10 Aug 2021 16:22:39 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-92-76-70-75-133.dsl.bell.ca. [76.70.75.133]) by smtp.gmail.com with ESMTPSA id b11sm5934711qtt.42.2021.08.10.16.22.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Aug 2021 16:22:38 -0700 (PDT) Date: Tue, 10 Aug 2021 19:22:37 -0400 From: Peter Xu To: Mingwei Zhang Cc: Jim Mattson , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm , LKML , Ben Gardon , David Matlack , Jing Zhang Subject: Re: [PATCH v4 3/3] KVM: x86/mmu: Add detailed page size stats Message-ID: References: <20210803044607.599629-1-mizhang@google.com> <20210803044607.599629-4-mizhang@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 09, 2021 at 05:01:39PM -0700, Mingwei Zhang wrote: > Hi Paolo, Hi, Mingwei, > > 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. The rmap statistics are majorly for rmap, not huge pages. > 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. I have a question: why change to using atomic ops? As most kvm statistics seems to be not with atomics before. AFAIK atomics are expensive, and they get even more expensive when the host is bigger (it should easily go into ten-nanosecond level). So I have no idea whether it's worth it for persuing that accuracy. Thanks, -- Peter Xu