From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751396AbcFXOzQ (ORCPT ); Fri, 24 Jun 2016 10:55:16 -0400 Received: from mga02.intel.com ([134.134.136.20]:7447 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbcFXOzO convert rfc822-to-8bit (ORCPT ); Fri, 24 Jun 2016 10:55:14 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,521,1459839600"; d="scan'208";a="724503171" From: "Odzioba, Lukasz" To: Peter Zijlstra CC: "linux-kernel@vger.kernel.org" , "x86@kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "ak@linux.intel.com" , "Liang, Kan" , "akpm@linux-foundation.org" , "eranian@google.com" , "acme@kernel.org" , "alexander.shishkin@linux.intel.com" , "bp@suse.de" , "Anaczkowski, Lukasz" Subject: RE: [PATCH 1/1] perf/x86/intel: Add extended event constraints for Knights Landing Thread-Topic: [PATCH 1/1] perf/x86/intel: Add extended event constraints for Knights Landing Thread-Index: AQHRwTqrE69m57LPLUuinULhCEnaQZ/fECsAgBMo30CAAXTWgIAFEmEA Date: Fri, 24 Jun 2016 14:54:04 +0000 Message-ID: References: <1465358536-21544-1-git-send-email-lukasz.odzioba@intel.com> <20160608064800.GN30154@twins.programming.kicks-ass.net> <20160621093739.GO30154@twins.programming.kicks-ass.net> In-Reply-To: <20160621093739.GO30154@twins.programming.kicks-ass.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzM0OWNiYTgtZWMzNC00MzRjLTk4NjktMzg3MTkzYTlkNDYzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ikd4Wml0dGVLSHNKMkZQcE1zK2JMNTdwMkt5OEdvelNLXC96SUpsUzVGVzE0PSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, June 21, 2016 11:38 AM, Peter Zijlstra wrote: > Yes, that is the intent, but how is this achieved? I'm not sure I see > how the patch ensure this. If you are confused, then it is likely that I did something wrong here. Let me explain myself. We already have a mechanism to create static constraints which limit events to given PMCs via event code filtering. Such constraints are later obeyed by event scheduler to assure that. Scheduler bases its decisions on idxmsk to place events on the right PMC. We can think of OFFCORE_RESPONSE/config1 values as an extension of event code making it 128bit long (code+extended code). Emask is extended code logically ANDed with extended code mask (analogy to c->cmask and c->code), we could add separate values here, but I didn't see a real use for it right now. Event code is used only in x86_get_event_constraints, so we have to extend event code matching check there to use config1 against our new emask. If constraint code matches event code and constraint has non empty extended code we check it against config1, if config1 uses one of the bits defined in emask we return constraint as if would be normal 64bit-code constraint, scheduler will take care of the rest. > Also, intel_get_event_constraints() has a path where it copies the > constraint, should it not also copy the new field? Since event code is not used anywhere except x86_get_event_constraints, so extended code is also not needed there. To verify that it works as I expect I added printk's to x86_assign_hw_event to see selected PMC. Thanks, Lukas