From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75B1AC433B4 for ; Thu, 15 Apr 2021 02:05:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C2C0610FA for ; Thu, 15 Apr 2021 02:05:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229612AbhDOCFx (ORCPT ); Wed, 14 Apr 2021 22:05:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbhDOCFv (ORCPT ); Wed, 14 Apr 2021 22:05:51 -0400 Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C5A3C061574 for ; Wed, 14 Apr 2021 19:05:27 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id f12so17093084qtf.2 for ; Wed, 14 Apr 2021 19:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:cc:date:user-agent:mime-version :content-transfer-encoding; bh=6xhuUVgjBAC1B6CSbTxZXzScfJ4bMKqw6vDHawJD1C4=; b=Jqmm8OgSc88cnUqwazmpGrij1003UuKustveP2GDVtNaaRF13m12U88Ofd/giO5FZ8 dw4kD5RR/jEHCJXIH+ne0DgEG0vjBXIcfNFCeqHDHDEE/8XLYFGLU+dhzh4b/KGYc/g0 kIMqpnV0UT5//s2nswOY/Re/fAmt3WgocLbT8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:user-agent :mime-version:content-transfer-encoding; bh=6xhuUVgjBAC1B6CSbTxZXzScfJ4bMKqw6vDHawJD1C4=; b=EzNy6O6sve3T49AlZABwyhuM1ZUpKcYjiVjDjtl2von29SXGShYoOkGFGxSjy/HlvP f4bMEjyeB11c1wo0rhKbNgxcJ1OeFoA5BOXTpyyKShu5KHzG1iEeZnsloy9UzZ7Ym+EU Hj5Y6TRgPTw3MTGoWR4TtXesxZmD2ndb04EtqxXz6B5Y5au7wQm68SDG7BGsv5zF7sAl HOi3kY3TjZByqsq8CPoT4aM3NpN61XE4W1cRss5ys2MwG6ni0MjD1gFn5QYPMetDuRYY 38KI9oQzMc4QlJr8dkCG8rSxzk2EtQqO+iiEqaT1vXqJ8UFlFFtZcADeEE51WJJdYbVY QQAA== X-Gm-Message-State: AOAM5317LfDFKfHRPJ6iMv7TYNpI1HNFGySDe1QSvhcfPEXbtvZunqPU rdattFoHTnREdRz7gsnFPVSOCw== X-Google-Smtp-Source: ABdhPJyFOL+4vGBXdOfpecXwAwZ83EwIJMAtJadyx0Rf90fufgsZ21AA3mETfYaoxkeAM+hhPvhxrw== X-Received: by 2002:ac8:45c6:: with SMTP id e6mr1017883qto.228.1618452326372; Wed, 14 Apr 2021 19:05:26 -0700 (PDT) Received: from saya.kepstin.ca (dhcp-108-168-125-232.cable.user.start.ca. [108.168.125.232]) by smtp.gmail.com with ESMTPSA id f27sm925917qkh.118.2021.04.14.19.05.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Apr 2021 19:05:25 -0700 (PDT) Message-ID: <88d11c19e662f67ae492eb4b93e12e1b24e68c1d.camel@kepstin.ca> Subject: [PATCH] Fix turbostat exiting with an error when run on AMD CPUs From: Calvin Walton To: Linux PM list Cc: "linux-kernel@vger.kernel.org" , Len Brown , Chen Yu Date: Wed, 14 Apr 2021 22:05:24 -0400 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The current version of turbostat exits immediately upon entering the main loop, with error code -13. This is a regression that was introducted in these commits: 9972d5d84d76 tools/power turbostat: Enable accumulate RAPL display 87e15da95775 tools/power turbostat: Introduce functions to accumulate RAPL consumption Which introduced a method to accumulate MSR values over long sampling durations. The commits failed to account for the fact that AMD CPUs use a different (but confusingly similarly named) MSR for reading the package energy. I've added the AMD version of the MSR to the methods so that turbostat can be run again. (If you run on a system with mixed Intel and AMD cpus, you might have problems, but I have been assured that this isn't likely in practice.) The MSR offsets in the conversion functions have been switched to use type off_t, since the offsets of the AMD MSRs exceed the range of a signed 32-bit int. Note that since the framework introduced only handles per-cpu MSRs but not per-core MSRs, AMD "Core" energy is not currently accumulated over long sampling periods. Fixes: 9972d5d84d76982606806b2ce887f70c2f8ba60a Signed-off-by: Calvin Walton --- tools/power/x86/turbostat/turbostat.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index a7c4f0772e53..576e03d373c4 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -291,13 +291,16 @@ struct msr_sum_array { /* The percpu MSR sum array.*/ struct msr_sum_array *per_cpu_msr_sum; -int idx_to_offset(int idx) +off_t idx_to_offset(int idx) { - int offset; + off_t offset; switch (idx) { case IDX_PKG_ENERGY: - offset = MSR_PKG_ENERGY_STATUS; + if (do_rapl & RAPL_AMD_F17H) + offset = MSR_PKG_ENERGY_STAT; + else + offset = MSR_PKG_ENERGY_STATUS; break; case IDX_DRAM_ENERGY: offset = MSR_DRAM_ENERGY_STATUS; @@ -320,11 +323,12 @@ int idx_to_offset(int idx) return offset; } -int offset_to_idx(int offset) +int offset_to_idx(off_t offset) { int idx; switch (offset) { + case MSR_PKG_ENERGY_STAT: case MSR_PKG_ENERGY_STATUS: idx = IDX_PKG_ENERGY; break; @@ -353,7 +357,7 @@ int idx_valid(int idx) { switch (idx) { case IDX_PKG_ENERGY: - return do_rapl & RAPL_PKG; + return do_rapl & (RAPL_PKG | RAPL_AMD_F17H); case IDX_DRAM_ENERGY: return do_rapl & RAPL_DRAM; case IDX_PP0_ENERGY: -- 2.31.1