Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp815982ybl; Fri, 10 Jan 2020 07:11:48 -0800 (PST) X-Google-Smtp-Source: APXvYqxD5tTrPuHQ8cYJb2ZTG5HoMVt0I9gAeASasmtD5pv50MEGx1xMlpf49G07487+XxgPlOS3 X-Received: by 2002:a9d:22:: with SMTP id 31mr2791850ota.173.1578669108110; Fri, 10 Jan 2020 07:11:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578669108; cv=none; d=google.com; s=arc-20160816; b=Shbno5V1Q3VwQC03Lhtx3wr+4PwMG1mhiDuBDWeYkSEZ69/GBRGSPzXm10RjfWvL2g V4AdnaE6s0/F6nitY0cbfLQRD8Our3pE9OvXmZwYWvzxNvKE8c4YCZYXXIDoQaw9ZpXS gBsrz8J2pCIYBYavngZ1lQbSGE5VfqoWP1vPeybcxnMQE0Rwf5cgtDGUzWtbS2hbanW3 mQ5NR7ZyXnfQh4RqhUaJ+Et7a7j3M2Dcjr9eiMsAnIfjl4SUvpwwFqQcV2QuyL/GmXx/ suTpw3FPHLxQrVF1JO8qgxKrfJWX+OKH3YcT6M+bSDtwXJfKniYeoeCJWo2z76WwEEU1 oJcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=EOly64n1bW9A8cciZ1GsSjqaul4aqxrKRoF/7rR8Npg=; b=d+PSR2ddDv3+BVl2evLDmxmaDPD31hOj6tVEnfYIPITg7IjH5cv/HHTfA7WrHStGT4 IJdhx633LS2L4J04B6DEv3g6VBl1lll88OJ0mcdq+FS8mHMH8VbpjaLPAqwiDhUYFkGk I52S1xX7ywVtQaY4/YxIahsTX+sOYSAglcu8p4c0+DczsRtclbaTqoeX1wOytOgbLCp4 5eBWQZmrPGw/3jnyNuvluqT2LnxKyfr2f9tg6cy4g+9qRdCQifL1Kml/BR3YFsPAyeQV B5mrDRR7ZoInO6/csiIyl5FL80rUstmsdt+F3dC0t2ZyfOoZxA7fBgiuSkTynT+Ayhu3 ItVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=1ZIaFRqc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c11si1328645oib.246.2020.01.10.07.11.34; Fri, 10 Jan 2020 07:11:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=1ZIaFRqc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728227AbgAJPK0 (ORCPT + 99 others); Fri, 10 Jan 2020 10:10:26 -0500 Received: from merlin.infradead.org ([205.233.59.134]:41414 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727855AbgAJPKZ (ORCPT ); Fri, 10 Jan 2020 10:10:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EOly64n1bW9A8cciZ1GsSjqaul4aqxrKRoF/7rR8Npg=; b=1ZIaFRqcaOBqY3PTIc2myc4/T 2bqFse/mCvbU0ZywdFOYX8JeeV82iaW4dhncF9xgCXu7AF6hHsxC3iNEef+Uh3EtTE5sE9O9Skv9E B4TAS69ZekjiuMOLRFlPh6NgjNLd3jMWouCAVNlTmBEZ+JAOa/8t8O4bPcMHUpHDcdmuFbrvOruBr /ZGsCe8QyHqGsWNSHsR2dX8HE7SuPYXOJVwmpo3E2yk4aWtrZPP/PhLlJhgGbGcGt0A+PxQBk/tdM c/Tdyh2c5e8DMidSd+HO9S2FjgqeFDBNfamwvg6UOsRt2O9AvRqnvpfdwaCFTSUBH3tZADHb8bVD9 ChUlgoC8g==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1ipvvF-0004gW-Jv; Fri, 10 Jan 2020 15:10:01 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 3460C30018B; Fri, 10 Jan 2020 16:08:24 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 202002B612601; Fri, 10 Jan 2020 16:09:58 +0100 (CET) Date: Fri, 10 Jan 2020 16:09:58 +0100 From: Peter Zijlstra To: Kim Phillips Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Janakarajan Natarajan , Suravee Suthikulpanit , Tom Lendacky , Stephane Eranian , Martin =?utf-8?B?TGnFoWth?= , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Thomas Gleixner , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org Subject: Re: [PATCH 2/2] perf/x86/amd: Add support for Large Increment per Cycle Events Message-ID: <20200110150958.GP2844@hirez.programming.kicks-ass.net> References: <20191114183720.19887-1-kim.phillips@amd.com> <20191114183720.19887-3-kim.phillips@amd.com> <20191220120945.GG2844@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 08, 2020 at 04:26:47PM -0600, Kim Phillips wrote: > On 12/20/19 6:09 AM, Peter Zijlstra wrote: > > On Thu, Nov 14, 2019 at 12:37:20PM -0600, Kim Phillips wrote: > >> @@ -926,10 +944,14 @@ int x86_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign) > >> break; > >> > >> /* not already used */ > >> - if (test_bit(hwc->idx, used_mask)) > >> + if (test_bit(hwc->idx, used_mask) || (is_large_inc(hwc) && > >> + test_bit(hwc->idx + 1, used_mask))) > >> break; > >> > >> __set_bit(hwc->idx, used_mask); > >> + if (is_large_inc(hwc)) > >> + __set_bit(hwc->idx + 1, used_mask); > >> + > >> if (assign) > >> assign[i] = hwc->idx; > >> } > > > > This is just really sad.. fixed that too. > > [*] > If I undo re-adding my perf_assign_events code, and re-add my "not > already used" code that you removed - see [*] above - the problem DOES > go away, and all the counts are all accurate. > > One problem I see with your change in the "not already used" fastpath > area, is that the new mask variable gets updated with position 'i' > regardless of any previous Large Increment event assignments. Urgh, I completely messed that up. Find the below delta (I'll push out a new version to queue.git as well). > I.e., a > successfully scheduled large increment event assignment may have > already consumed that 'i' slot for its Merge event in a previous > iteration of the loop. So if the fastpath scheduler fails to assign > that following event, the slow path is wrongly entered due to a wrong > 'i' comparison with 'n', for example. That should only be part of the story though; the fast-path is purely optional. False-negatives on the fast path should not affect functionality, only performance. False-positives on the fast path are a no-no of course. --- diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 222f172cbaf5..3bb738f5a472 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -937,7 +937,7 @@ int x86_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign) * fastpath, try to reuse previous register */ for (i = 0; i < n; i++) { - u64 mask = BIT_ULL(i); + u64 mask; hwc = &cpuc->event_list[i]->hw; c = cpuc->event_constraint[i]; @@ -950,6 +950,7 @@ int x86_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign) if (!test_bit(hwc->idx, c->idxmsk)) break; + mask = BIT_ULL(hwc->idx); if (is_counter_pair(hwc)) mask |= mask << 1;