Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp748674rwb; Thu, 8 Dec 2022 02:24:15 -0800 (PST) X-Google-Smtp-Source: AA0mqf49nAshEVE2xKIJQLVn5v9WlZ2BGUmz8az/uVMT94KF8K+FL0xtXhTkKUx/nVPD02SxWIWc X-Received: by 2002:a63:1f21:0:b0:46b:2bd4:f298 with SMTP id f33-20020a631f21000000b0046b2bd4f298mr70128039pgf.135.1670495055339; Thu, 08 Dec 2022 02:24:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670495055; cv=none; d=google.com; s=arc-20160816; b=Tpv0LbM0I8MEHO5k+OGhNLWiGvVqJmKDKuXrM73PPeTDpCwOj46of81rXhJCYHZCVO NEH9YhydJq5lZyfaHvgqd9sQWO/ySai7X0XpMFC5PcLvx5ruWs5YYSkojRkRF36nBc+R qQutGxrThG16wyGsfiM14LMLRXLMYDdMg+xg8AnqQSXv+oaSSWZt9hEmqP9zNN6rSDT9 pI0607zSoDcvPCuDT/pl4QGWVFiT6PnifnM6ae6Nj9clH6gkwDnW8wF/xjGA/1UN9luJ /raC4CjJDyN0lhNcCyiW6k0k5O4zpGN4n1Fvi6OOl1k9N2vptJwO+Fo9Pikhbb4nQVz1 H/KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=P6pNB2x50dYwPB4We2hSd93Dmio7/AlO8hDxzk/4tCw=; b=lryf/O57wQCcd9fnVMuxaj/6qb7J4ZB6g+9KbEiFTMaK7sRSlXdyrodHgwbDbSP46P IV6iTuRiL5x0yDXLpzxozL6ct2qpscpZodacAcnfU8GT5LvddChauy9Da0U2nq7KwlUO KrGcJnBt/CmaXech4XoIieNFkYr+b644coNXseMjfu62mHpU7Aw07cIPD/p9URneerZd 83203YxvNa+lJY6lskNNAjFhGuf0jxMk+Y4P95x+ATqFod9zjHqhfMQN7iDnREICdLy8 d5HLXxcvPp4aWK/LrP8ozi925LRTbaPvyeJjIKs481gRf/Jx9zgr91fmqscGPto3PE3l lYiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="ak/Rkejm"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c21-20020aa78e15000000b0055fa098c388si22529958pfr.259.2022.12.08.02.24.06; Thu, 08 Dec 2022 02:24:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="ak/Rkejm"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229809AbiLHKEh (ORCPT + 72 others); Thu, 8 Dec 2022 05:04:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229550AbiLHKEf (ORCPT ); Thu, 8 Dec 2022 05:04:35 -0500 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBB6A532E9 for ; Thu, 8 Dec 2022 02:04:33 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id o127so1042056yba.5 for ; Thu, 08 Dec 2022 02:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P6pNB2x50dYwPB4We2hSd93Dmio7/AlO8hDxzk/4tCw=; b=ak/RkejmjE9qBHSNqj/DVX7HZMtXL36JXOtFhwWu/JegmQD5w0URdN8S69uKLMYnTl 32DfDuzhOp5MycxVprxksq/02jDMd4Yd1dtC1bQ1MtHktvY8N9v7e+ke4xsrTceVjy7c 7DaMql3hHig3FJIY2t1meg5htoSlQOHUA36Z00lA/x1l6N4en3qYeVnvpkW9IMDC7lj5 Y3hr+VtDVB1Y33PNnMMpMvB59JzkvmJoLDKGXHDDmukaLenn/0VO+ln1+Zv9eKUfqM3/ qSpeNxphxSjPN57+2PAet1DN6hD3vHFvkRcpG98N2r9vrCQowaBDb2t/9LwXgNS4jJaD AspQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P6pNB2x50dYwPB4We2hSd93Dmio7/AlO8hDxzk/4tCw=; b=H7PtudBLjHZsciYkS6ubNqMvsaKaz00Y/X3udBN83ZSdFsPOWJwiWN+wYLmkghIKM5 bdfXX5WxO6Dmyrw0lYindVw6lfixGBM7Sgmros+MNbqF7V4KNBZQQeGo/W8SfLghWQGH RePfEfNG3e3SyefJ3MR6MqrOTBjo5TGOy1VIfVOz169mjYCVj2/mngS98/YZZ8p1SUks LW8UaMt7vsVx6jA4NpS62m0tI/GcDlYnvtkL72BAcq1U4ljH3LV74Z7sB6edNJPYlCyu ntVI5FQD1CmLxIpNwxJqxtHm2evgyM61G2SjeQr0/kmEKT4RfwFvBgM2I+BTaNhiMqoq a6rg== X-Gm-Message-State: ANoB5plN+9p1zJPLOyVI6yFtuY8L9jd8pOT5hQ2J8uEgt6kKp/I6ne9y iXzySb5Gl/By9Ogw+FJ7FbekYjWtK4N18eCym4q3WQ== X-Received: by 2002:a25:bc8f:0:b0:6fc:8f79:2368 with SMTP id e15-20020a25bc8f000000b006fc8f792368mr28510597ybk.399.1670493873037; Thu, 08 Dec 2022 02:04:33 -0800 (PST) MIME-Version: 1.0 References: <20221207112924.3602960-1-peternewman@google.com> In-Reply-To: From: Peter Newman Date: Thu, 8 Dec 2022 11:04:22 +0100 Message-ID: Subject: Re: [PATCH] x86/resctrl: Fix event counts regression in reused RMIDs To: Reinette Chatre Cc: Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , James Morse , Shaopeng Tan , Jamie Iles , linux-kernel@vger.kernel.org, eranian@google.com, Babu Moger Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Reinette, On Wed, Dec 7, 2022 at 8:48 PM Reinette Chatre wrote: > > To get back to the original behavior before the refactoring it also seems > that __mon_event_count() needs to return right after calling > resctrl_arch_reset_rmid(). The only caller with rr->first set is when > the mon directory is created and the returned values are not used, > it is just run to get prev_msr set. This also avoids unnecessarily reading > the counters twice. > > So, how about: > > static int __mon_event_count(u32 rmid, struct rmid_read *rr) > { > > ... > if (rr->first) { > resctrl_arch_reset_rmid(rr->r, rr->d, rmid, rr->evtid); > return 0; > } > ... > > } Avoiding the double-read sounds good, but... > > Also ... there appears to be a leftover related snippet in __mon_event_count() > that does not belong anymore and may still cause incorrect behavior: > > static int __mon_event_count(u32 rmid, struct rmid_read *rr) > { > ... > if (rr->first) { > memset(m, 0, sizeof(struct mbm_state)); > return 0; > } > ... > } I'm less sure about removing (or skipping) this. mbm_state::mbm_local still seems to be used by the mba_sc code. That might be why James left this code in. I was sort of confused about the new role of mbm_state following the refactoring when reviewing Babu's change. (which reminds me that I should have CC'ed him on this patch) -Peter