Received: by 2002:a05:7412:bbc7:b0:fc:a2b0:25d7 with SMTP id kh7csp987493rdb; Fri, 2 Feb 2024 09:50:41 -0800 (PST) X-Google-Smtp-Source: AGHT+IFBmVjm5ezqNH1KcKp+mZk+XUI/oVv9MyboEtUvWlJFxpUucULh6xIcvW+Hlgis2xVsSXyO X-Received: by 2002:a05:6a21:3101:b0:19c:84ef:a242 with SMTP id yz1-20020a056a21310100b0019c84efa242mr2937680pzb.43.1706896241192; Fri, 02 Feb 2024 09:50:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706896241; cv=pass; d=google.com; s=arc-20160816; b=cn9J9wI/Ltso0aFBOyiJK2dPKUew9csO43DTwo/1aofBsftgJjABiwIzQy+gtLqy7z 8mOcSQLmWpgBiK3IxZsxV4dj8HkWV7Jfhu2EU7M1UTyZPNNDEn6VwqvsBGTy1TMcxUhs Vt1tTb/q1uBnuDSVGpcTKZrSdcSTqCq3S/vu5RtI6LU5K26eKwjWjCkAHsGoiGAYLrPI B5xgQHmFaE1A7SzUknswHn/8WPpOZF1jCI422x/mPejeyxy8+CRzslbH6w6wvp+Z6uZT oTbsKpUryzt1y40EDe6seqz2Xfmsk6SuCViIHi3FProNYQOTKs+NCMohThsf61VQY/Jt MBbg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:from:subject:message-id:references:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:in-reply-to:date :dkim-signature; bh=Jh8tPI6zDKBJW5XNFKGiR3+xJf/t/qaa3P1NxbupNfc=; fh=/OCnexcvl5L2fRpf6KzMD8BiF4Eu0Pwq5ftd4y65/4E=; b=TpkaWFdK93berNPN8BxTRrB46cIad2joK5FT2QnsjBeVwT7hHz8wCo+0wxSqpbCsdH WhB7mW96bYyMIVK/P9AXlIy22mB8wi6JF3cgg5LE0e/U+S9UDodOniPEBdKKfBB1Z7Ra 6GfoT7Nac687OKu09UdweMTuqtEUlFy2UcIhiz3hLYWe/baWxwsuCDNOTzlMQDBKr/kl EvxPp4bg2NbW4qqm3YnOVN91H4kdtj3l7sDBKyEWugZTupAusSPd2vs5WQOloxvXGn8C c+cIPcOBTV5tNOExa0nRVRQjDU9abh0fyNSJrMGHu08uHpAqeWSbOCafMkxUYUUVqyQE b0Zw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=dz87J7uG; arc=pass (i=1 spf=pass spfdomain=flex--seanjc.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-50228-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50228-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Forwarded-Encrypted: i=1; AJvYcCVoPzRrWJ+J89w1zVlOaeQ/daaBqIWrPtnzpw1hvvEsqS2oVWzFb6M0v2FljFB1rvKPYTWr0DOKn70MRh1x99uRy1ZLgySv7CKGoJYkWw== Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id y3-20020a63ce03000000b005d8c57281dfsi1920485pgf.410.2024.02.02.09.50.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 09:50:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-50228-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=dz87J7uG; arc=pass (i=1 spf=pass spfdomain=flex--seanjc.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-50228-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50228-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 78FE3B289A2 for ; Fri, 2 Feb 2024 17:24:33 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8FEC214A4FC; Fri, 2 Feb 2024 17:24:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dz87J7uG" Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 283201799A for ; Fri, 2 Feb 2024 17:24:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706894658; cv=none; b=VhXV0fWnYYHm3boHrq1DmoBsW7G7yARcHbEslzzQk/Z/1ou37RkU38a4C9ycaznTIGpKv0I3QBsBBVpuDjNktKwLCTDOVV+IMVbC65D//a98nH4QeGSLmQCnCdyzw42HLG6M8g2RrcuYI4drcZkixROofXbpcWeYKhYOGp8JxXQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706894658; c=relaxed/simple; bh=f4w3yfckQ6AIGjZw7uQb+qgVSH6aBp1dXcAlQ6VCmsU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Z4RGdanf5CmTtK7ygHuveVn6aQ8fJcOTB3wqJUD3n/m6TDI1hbEggX85rQUK1wZnQaa1qEpBvX7kEkJuh/KU+fPDlcruLB0vqsIbSTJosnCzUYDMMcVUUsSYlaU1IPKcJ/D72bZz5VPpCntgnpcHnSkX6Ggye/vx3kcxplN/e7Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=dz87J7uG; arc=none smtp.client-ip=209.85.219.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-dc6c47cf679so4101460276.0 for ; Fri, 02 Feb 2024 09:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706894655; x=1707499455; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Jh8tPI6zDKBJW5XNFKGiR3+xJf/t/qaa3P1NxbupNfc=; b=dz87J7uGkmnmxHC2AnQ3HtNip0UaCBr7GjH6znlI+p7a9KTR1/Wpc4yqszeMlVUMXy Wg/l+g/iYttu3F38uZJAqxsx4UHMeu8Tilan6pfa8yYUB5j2SUapdP4gzrWQI2nPcenr +NB5yzxv6sz17S5hrlrASkwhtXrl8v6PRPWhuBkF+vDzoHl54tkiQztiVIEeVZwO9fPb 7C/FMVoeKM2DJZuwSXws/kwxMUdLrYIYHRshb9GKdXPAOXxuPRHi94a9IycFjBCmPQjp YGPuxcShR+RD2DlXDpx5POg2NJxbpzO6jfImbkZZiDozv0VeFNtRhQBg8SR24CGgJqyu 46Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706894655; x=1707499455; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Jh8tPI6zDKBJW5XNFKGiR3+xJf/t/qaa3P1NxbupNfc=; b=c+5rD5N60S2lAUrBgDQYwSsUZutkyux1PhNxhCDMgSkTDU67GrMac31fWcWhpyLPmf dXqRaJZ7Eg/0SjX6vkqrI8R9OH3Ocn2DtsqHXIrCf0oc3MSTbazYsE861ZaPM3U4nE06 4MK3Y7lMEMRLitckkOuv8jgVfSVV6MOXr1XwF1cnv/96t/lhuGgFqzGjZ4cab26INQza PZitqtD/3oC1MqXk1jEMYd0LAAl/+SeryzhQG05fnTxm+eyYgqUvWH4PxeUzt1V317t4 +MojtaTlCVYA7UtmOZM/qgj4KWi0Y1rqPYoJ/89NNOUHjCJGN3AqSiLVPtf+bab/+0md AOiA== X-Gm-Message-State: AOJu0Yy8zZZqsmzvWpA/DN/66IUjJORm8AAQx5DAKyh8Y9t8sB39ey7E YJa+ctX12tKGOKGv2q+MRJdI0TqeyVP1OSixwwEN28wHtXcrkNYoYimG9AkLCg+SuYPJt/2murQ I4A== X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:200a:b0:dc2:3441:897f with SMTP id dh10-20020a056902200a00b00dc23441897fmr748244ybb.6.1706894655216; Fri, 02 Feb 2024 09:24:15 -0800 (PST) Date: Fri, 2 Feb 2024 09:24:13 -0800 In-Reply-To: <95c3dc22-2d40-46fc-bc4d-8206b002e0a1@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240201061505.2027804-1-dapeng1.mi@linux.intel.com> <95c3dc22-2d40-46fc-bc4d-8206b002e0a1@linux.intel.com> Message-ID: Subject: Re: [PATCH] KVM: selftests: Test top-down slots event From: Sean Christopherson To: Dapeng Mi Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Kan Liang , Jim Mattson , Jinrong Liang , Aaron Lewis , Dapeng Mi Content-Type: text/plain; charset="us-ascii" On Fri, Feb 02, 2024, Dapeng Mi wrote: > > On 2/2/2024 2:02 AM, Sean Christopherson wrote: > > On Thu, Feb 01, 2024, Dapeng Mi wrote: > > > Although the fixed counter 3 and the exclusive pseudo slots events is > > > not supported by KVM yet, the architectural slots event is supported by > > > KVM and can be programed on any GP counter. Thus add validation for this > > > architectural slots event. > > > > > > Top-down slots event "counts the total number of available slots for an > > > unhalted logical processor, and increments by machine-width of the > > > narrowest pipeline as employed by the Top-down Microarchitecture > > > Analysis method." So suppose the measured count of slots event would be > > > always larger than 0. > > Please translate that into something non-perf folks can understand. I know what > > a pipeline slot is, and I know a dictionary's definition of "available" is, but I > > still have no idea what this event actually counts. In other words, I want a > > precise definition of exactly what constitutes an "available slot", in verbiage > > that anyone with basic understanding of x86 architectures can follow after reading > > the whitepaper[*], which is helpful for understanding the concepts, but doesn't > > crisply explain what this event counts. > > > > Examples of when a slot is available vs. unavailable would be extremely helpful. > > > > [*] https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2023-0/top-down-microarchitecture-analysis-method.html > > Yeah, indeed, 'slots' is not easily understood from its literal meaning. I > also took some time to understand it when I look at this event for the first > time. Simply speaking, slots is an abstract concept which indicates how many > uops (decoded from instructions) can be processed simultaneously (per cycle) > on HW. we assume there is a classic 5-stage pipeline, fetch, decode, > execute, memory access and register writeback. In topdown > micro-architectural analysis method, the former two stages (fetch/decode) is > called front-end and the last three stages are called back-end. > > In modern Intel processors, a complicated instruction could be decoded into > several uops (micro-operations) and so these uops can be processed > simultaneously and then improve the performance. Thus, assume a processor > can decode and dispatch 4 uops in front-end and execute 4 uops in back-end > simultaneously (per-cycle), so we would say this processor has 4 topdown > slots per-cycle. If a slot is spare and can be used to process new uop, we > say it's available, but if a slot is occupied by a uop for several cycles > and not retired (maybe blocked by memory access), we say this slot is stall > and unavailable. In that case, can't the test assert that the count is at least NUM_INSNS_RETIRED? AFAIK, none of the sequences in the measured code can be fused, i.e. the test can assert that every instruction requires at least one uop, and IIUC, actually executing a uop requires an available slot at _some_ time. diff --git a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c index ae5f6042f1e8..29609b52f8fa 100644 --- a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c +++ b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c @@ -119,6 +119,9 @@ static void guest_assert_event_count(uint8_t idx, case INTEL_ARCH_REFERENCE_CYCLES_INDEX: GUEST_ASSERT_NE(count, 0); break; + case INTEL_ARCH_TOPDOWN_SLOTS_INDEX: + GUEST_ASSERT(count >= NUM_INSNS_RETIRED); + break; default: break; }