From mboxrd@z Thu Jan 1 00:00:00 1970 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dz87J7uG" 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-Google-Smtp-Source: AGHT+IFYznk7JpLxuRok8AtJlpZ2llmKQpQE42vIimTuUoL3PWXT0NTUQQ7owcgwAoNNjSDys4Q9Eh7vX8A= 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; }