Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp22605img; Tue, 19 Mar 2019 16:56:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqzByTwyAnbr2CqE9nUrlH58RGgFZdOw6NBFB+8wiLqujvxtzu+79utgK93VdvhqhO2pYp2J X-Received: by 2002:a65:534d:: with SMTP id w13mr25175440pgr.186.1553039780647; Tue, 19 Mar 2019 16:56:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553039780; cv=none; d=google.com; s=arc-20160816; b=KsClEVQitV5/hSYqmL0mAd/E5y32aoA3pHVYLkooJZJpXAqUQxMxNIE8LqGvDxSJVK M2tFDh3aHql16IkNarSK9wSVmPtOGt0Mi3R5RtgcHu0L2QxeK3mDsl8Npecxh0F1IYnW 2DULAtMBm3PoHRkbfLgfM1f+XoJPDyX8fDiHEUWPmwO9RJfze9GaVpK1Cv/ZFIpLBbkj EMt5knZejo5Q4AJfogo/HvPzhB7k5EzMNNMPo0N4OYPy9olA+Zg9Fdouh0pVscFuM1XK a6Nz6fBdpt7ELb3ll9f+1grG8qetA9HMcY8XxYxpvyZUyKsOBlqO6Kk0kXdz7CuD944C dN7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=1Uo8/7TYT9iFgR0+P4tx7d6/0m83KYczJ7RAbix01Nw=; b=qAZbHfnPYLZPp3d06upsqfk0/9+VLVqKD3HkSUrVaYIdlPIvhqj4LIPo17buYsCdBG pZ5Mbsb39SvmuATheUCeNtcmHhtHiE6k+u2MlToS+yXLOxvH33GuXCp6oFO2cPj196mq 4/YvREzbVVyYjDCyzDlAwZImYhB5Qhubs5E22luVtp6ODhvx9WLXdZFXzdgnb3C9jk5b cCR2B7SPUwYmFlQ7LTuMTIyPge36g0S6Oniui4mvqra2APNGcBrerkNrzw3SKdCkPwxC /6QWMvZjmn4tlVW7510mvRs6jUugN5vHkfhZdtyarun4sjejooAmEzRmiZdQMPzJteIM EMug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FMq59NM9; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f9si123230pgc.576.2019.03.19.16.56.04; Tue, 19 Mar 2019 16:56:20 -0700 (PDT) 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=pass header.i=@google.com header.s=20161025 header.b=FMq59NM9; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726969AbfCSXz3 (ORCPT + 99 others); Tue, 19 Mar 2019 19:55:29 -0400 Received: from mail-ua1-f68.google.com ([209.85.222.68]:40368 "EHLO mail-ua1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726686AbfCSXz2 (ORCPT ); Tue, 19 Mar 2019 19:55:28 -0400 Received: by mail-ua1-f68.google.com with SMTP id b8so205855uaq.7 for ; Tue, 19 Mar 2019 16:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1Uo8/7TYT9iFgR0+P4tx7d6/0m83KYczJ7RAbix01Nw=; b=FMq59NM9fQiCuzKEQKDzjmmn4lQeU77bUKVQ0kuLK5luT81fq+ZH6ap1kLv7cptnEP cix72py5P9Mt1Cpeu2RgBGC/KUjjBirsk0rKhLxoqS1j8UZu5fGqo89dZMraKZ15MD3r DbCn8huwXPdIxqz1AuXn1EMsckuumPkfd0G1EuJxk+Mf59jq/7aIBG7l22WjbvzYA9I8 1vk7cq8UZ/Q4Ek00YjCSMLgkaQq4Sd+Ph0koxEi5IMPC56ZmoMvbaNrSL3mAbuEsNCY1 OKTY1FbhkT/PO11ethT/Fg9BeeJREpIn7bbDw4I8U30bVQYhzTne1lTDo4F1YHwDmN0o /DpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1Uo8/7TYT9iFgR0+P4tx7d6/0m83KYczJ7RAbix01Nw=; b=P2/X/ZZZoKxGu4JmoRO0Kp7P9KR1zNEvZHOiWVLDSxpiepo0O13D5gsWeripFbyLYZ wqb7XRxgmItgpXdbbYfoSs3DzZbYheEf2sNvh8ZhsbOv7xKL4n6DI8aJkxBqm24Kzx4v P+LCJ7NSHpdGDQVczZqZCG14ePHEAXmjCkqRehSCr2yqto8fLi0QffTMKE7QiwnsNOKw F2rLTjc6C1YRCHNCcarQQMsMGeXW5w6G/4sx0H/i3YA1pcsaX6shvJBcUXzo/24pPA8s CiFzUYMHQ0AL0SohwakFo9FNE5X83hJ1rQHh27xph6E7qU7/j06I28Zpoel+i83elr2z lUVA== X-Gm-Message-State: APjAAAXp5B66y0+CXTYTigXtqEgiIsI5tahoOtV8towucPTigNGAhGtK svxfKonjX+gvHncktf36Ellp/n2D2qInREGICNJafw== X-Received: by 2002:ab0:6787:: with SMTP id v7mr2916443uar.38.1553039727431; Tue, 19 Mar 2019 16:55:27 -0700 (PDT) MIME-Version: 1.0 References: <20190314130113.919278615@infradead.org> <20190314130706.061994422@infradead.org> In-Reply-To: <20190314130706.061994422@infradead.org> From: Stephane Eranian Date: Tue, 19 Mar 2019 16:55:16 -0700 Message-ID: Subject: Re: [RFC][PATCH 7/8] perf/x86: Optimize x86_schedule_events() To: Peter Zijlstra Cc: Ingo Molnar , Jiri Olsa , LKML , tonyj@suse.com, nelson.dsouza@intel.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 14, 2019 at 6:11 AM Peter Zijlstra wrote: > > Now that cpuc->event_constraint[] is retained, we can avoid calling > get_event_constraints() over and over again. > > Signed-off-by: Peter Zijlstra (Intel) > --- > arch/x86/events/core.c | 25 +++++++++++++++++++++---- > arch/x86/events/intel/core.c | 3 ++- > 2 files changed, 23 insertions(+), 5 deletions(-) > > --- a/arch/x86/events/core.c > +++ b/arch/x86/events/core.c > @@ -844,6 +844,12 @@ int perf_assign_events(struct event_cons > } > EXPORT_SYMBOL_GPL(perf_assign_events); > > +static inline bool is_ht_workaround_active(struct cpu_hw_events *cpuc) > +{ > + return is_ht_workaround_enabled() && !cpuc->is_fake && > + READ_ONCE(cpuc->excl_cntrs->exclusive_present); > +} > + > int x86_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign) > { > struct event_constraint *c; > @@ -858,8 +864,20 @@ int x86_schedule_events(struct cpu_hw_ev > x86_pmu.start_scheduling(cpuc); > > for (i = 0, wmin = X86_PMC_IDX_MAX, wmax = 0; i < n; i++) { > - c = x86_pmu.get_event_constraints(cpuc, i, cpuc->event_list[i]); > - cpuc->event_constraint[i] = c; > + c = cpuc->event_constraint[i]; > + > + /* > + * Request constraints for new events; or for those events that > + * have a dynamic constraint due to the HT workaround -- for > + * those the constraint can change due to scheduling activity > + * on the other sibling. > + */ > + if (!c || ((c->flags & PERF_X86_EVENT_DYNAMIC) && > + is_ht_workaround_active(cpuc))) { > + > + c = x86_pmu.get_event_constraints(cpuc, i, cpuc->event_list[i]); > + cpuc->event_constraint[i] = c; > + } On this one, I think there may be a problem with events with shared_regs constraints. Constraint is dynamic as it depends on other events which share the same MSR, yet it is not marked as DYNAMIC. But this may be okay because these other events are all on the same CPU and thus scheduled during the same ctx_sched_in(). Yet with the swapping in intel_alt_er(), we need to double-check that we cannot reuse a constraint which could be stale. I believe this is okay, just double-check. > > wmin = min(wmin, c->weight); > wmax = max(wmax, c->weight); > @@ -903,8 +921,7 @@ int x86_schedule_events(struct cpu_hw_ev > * N/2 counters can be used. This helps with events with > * specific counter constraints. > */ > - if (is_ht_workaround_enabled() && !cpuc->is_fake && > - READ_ONCE(cpuc->excl_cntrs->exclusive_present)) > + if (is_ht_workaround_active(cpuc)) > gpmax /= 2; > > unsched = perf_assign_events(cpuc->event_constraint, n, wmin, > --- a/arch/x86/events/intel/core.c > +++ b/arch/x86/events/intel/core.c > @@ -2945,7 +2945,8 @@ intel_get_event_constraints(struct cpu_h > * - dynamic constraint: handled by intel_get_excl_constraints() > */ > c2 = __intel_get_event_constraints(cpuc, idx, event); > - if (c1 && (c1->flags & PERF_X86_EVENT_DYNAMIC)) { > + if (c1) { > + WARN_ON_ONCE(!(c1->flags & PERF_X86_EVENT_DYNAMIC)); > bitmap_copy(c1->idxmsk, c2->idxmsk, X86_PMC_IDX_MAX); > c1->weight = c2->weight; > c2 = c1; > >