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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 717A9C433ED for ; Tue, 20 Apr 2021 14:42:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2A7A6613C9 for ; Tue, 20 Apr 2021 14:42:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232731AbhDTOm5 (ORCPT ); Tue, 20 Apr 2021 10:42:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232304AbhDTOms (ORCPT ); Tue, 20 Apr 2021 10:42:48 -0400 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E813AC06174A for ; Tue, 20 Apr 2021 07:42:16 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id s5so30752897qkj.5 for ; Tue, 20 Apr 2021 07:42:16 -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:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=JP+ANeZGsccJBmVoGo/R3MoTa5r6RLwf9o2mfl/oBZ8=; b=COOJenwoW6uh0/Vq0jN5GTwm1bTMt4rdcgNhpEGTAHhrcnFTGCWvI3UtNLIwTap5Oq 3NJbypfQIG2Xm1C2yHEKa/jJl4EaBtWa3lgUbYkwroZRR0NaS43fRKwEvDVVXEESfQQz xTlubm552SfeYZ28MeqxsGbbuhz2R0UHKJHJU= 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:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=JP+ANeZGsccJBmVoGo/R3MoTa5r6RLwf9o2mfl/oBZ8=; b=IC7WeItbnKTaVC6ugIl4kSaDp+2j8Lvt8Wx0jd1Wa2yHkS/g66JQt9d7eN3a9vsIAd /IYxJtPHXE+Nd3kenAFMAv0beKRAnzfarNCfp83KBbVbJFWz2XspclWgVHbE9jAgdoBb kUMJ+Fb4ZmRN2J2CF9kX97TrtACnC5ollgnt3TrNwXiLoIvu1/5/QWBf/euiCoefoscC YY4iwd9zhjlv2Pu950J0m+qfki/0QGR0PNKJwaNAeu9GBNfGZUvpHWPyPQ+PPs91ed1o Vw+5yM3xtOW8Aircxgp8hZoVhxEbJ2OXs/Ig3ZfanG/5WJ+YkwKEBxlfA2su+4y+Rz/u LwYA== X-Gm-Message-State: AOAM531OV0Ze1TXsTkE+8zGEIMZVluAW5Px91QQt2kN2ssd7cUuCgBMt y3zJy1A+YcTboQ3hZYbsR4MVbg== X-Google-Smtp-Source: ABdhPJzH5l6jQWUBOv0JJzlNg3WbGpqgIqRjvadTeAryOnar6niI9K3UG0bw9u4jkyfRcWaq1bwobw== X-Received: by 2002:a05:620a:e1a:: with SMTP id y26mr18058355qkm.280.1618929736067; Tue, 20 Apr 2021 07:42:16 -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 p21sm10223024qkp.92.2021.04.20.07.42.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Apr 2021 07:42:12 -0700 (PDT) Message-ID: <5cf35f3742d1181421d955174b1aa9434d042c96.camel@kepstin.ca> Subject: Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors From: Calvin Walton To: Chen Yu Cc: Borislav Petkov , Terry Bowman , lenb@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, wei.huang2@amd.com, aros@gmx.com, rui.zhang@intel.com Date: Tue, 20 Apr 2021 10:42:09 -0400 In-Reply-To: <20210420143754.GA390118@chenyu-desktop> References: <20210419195812.147710-1-terry.bowman@amd.com> <20210420020336.GA386151@chenyu-desktop> <20210420080701.GA2326@zn.tnic> <20210420131541.GA388877@chenyu-desktop> <4cbb1eff77de1e843912267ade4686cfa1acd610.camel@kepstin.ca> <20210420143754.GA390118@chenyu-desktop> 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 On Tue, 2021-04-20 at 22:37 +0800, Chen Yu wrote: > On Tue, Apr 20, 2021 at 09:28:06AM -0400, Calvin Walton wrote: > > This patch has the same issue I noticed with the initial revision > > of > > Terry's patch - the idx_to_offset function returns type int (32-bit > > signed), but MSR_PKG_ENERGY_STAT is greater than INT_MAX (or > > rather, > > would be interpreted as a negative number) > > > > The end result is, as far as I can tell, that it hits the if > > (offset < > > 0) check in update_msr_sum() resulting in the timer callback for > > updating the stat in the background when long durations are used to > > not > > happen. > > > > For short durations it still works fine since the background update > > isn't used. > > > Ah, got it, nice catch. How about an incremental patch based on Bas' > one > to fix this 'overflow' issue? Would converting offset_to_idx(), > idx_to_offset() and > update_msr_sum() to use off_t instead of int be enough? Do you or > Terry have interest > to cook that patch? For Terry's version, I'm not sure if spliting > the code into different CPU vendor would benefit in the future, > except > that we would have plenty of new MSRs to be introduced in the future. Yes, I believe updating the offset_to_idx(), idx_to_offset(), and update_msr_sum() functions is sufficient. I can do the incremental patch for that this evening if nobody beats me to it :) -- Calvin Walton