Received: by 10.223.148.5 with SMTP id 5csp7438083wrq; Thu, 18 Jan 2018 05:34:34 -0800 (PST) X-Google-Smtp-Source: ACJfBoseRi3RrTCOIHpnwbpaBtJBdf6oZgos7gZyneLy0s6mmsPRxqv3OwK9kBwDaJ1uVkI9c+XY X-Received: by 10.98.170.24 with SMTP id e24mr17329062pff.177.1516282474414; Thu, 18 Jan 2018 05:34:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516282474; cv=none; d=google.com; s=arc-20160816; b=td505wIaDIykAdH6FrTByK2/Vlh347OEckS29OsATeY1UsW6C+mdpz6q2iswAwlfXP XTM1QT1ut/BxP+r9VLNVgq1W4pWh81lyM2Jt1MXEit9usPVTQHGTfdk1jHFTypGOm6PA 2NbTccFYrtrsgzgtHnYxEDEzDnIP2V/g3MhNxYWRoKxIgWZm/OH6WS4VKNL+9PGJfPGS uGSAHP9j6eAKG74mOKzwBJLNd6ykj2pb82EqqpWV5U1UbTMJEGhU/Xvk2xZ1taHjEGwT gqUqufipNN2xmTS9P0PxdBKg4MsjCnO/epbwRMVFsIpYHp/sn3CtsbUXEpBSoB5Ic+tg XkOw== 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:arc-authentication-results; bh=zndrtXAhdLJFBC7UWUw7v2g5Li76YjH5lgaNL6ki+Yo=; b=vMRY1u7mMzBOQ79HuTKUTyw6IWf6FpKwG61FTlFheJVHIAG4x5soe3po0ujOKa0to2 lsA8hxabr8bj7b0wjT+uBF5BRELtjY+E7ADfV2WIBVfewL52oUA+JCe9Y0rdR5iXaUDz hr7RQEK0ERhOa/VXdW5W+cPBEfDfU+vMp57y+5fMQqPwfkYnf7uKlBjLPYk2sDWuBXj/ 6k4MjmPo0/X2XwzjJpp7ryPQus1WHhwXa/gAMSd5+03uCFbP2e/PD+X3GptLyb71Ecsk +dJOXjc1wUONTud63di7P3grYch83ahbp1aVCAsFQEOPpDMHK/VUDKKvAa94CurBfd1b Qj2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=YYVdtDKQ; 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 u9si1166528pfj.183.2018.01.18.05.34.19; Thu, 18 Jan 2018 05:34:34 -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=bombadil.20170209 header.b=YYVdtDKQ; 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 S1756258AbeARNc5 (ORCPT + 99 others); Thu, 18 Jan 2018 08:32:57 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:57373 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755690AbeARNc4 (ORCPT ); Thu, 18 Jan 2018 08:32:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.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=zndrtXAhdLJFBC7UWUw7v2g5Li76YjH5lgaNL6ki+Yo=; b=YYVdtDKQ/ZwvNNigZoCkwaKI1 y4Ahjl6DGUk1RYce093vgGVquWtK5XzyqmdHPLgsD56SAPvF6keA9upo0phNrEtRpjwFQLSkW0YqN d0GaJt6uQzNOU65vlPFFDOL8dzniMvaV3XpVEbG++GcgWrVTpQ2ERDBFT4Z5x1/bSt0hVEKCdE4Ua Iny4908MsTfbvqLP8fQ+tcYFzh7Q/uqBQlPmJ0IMNPcU/q02oFX2ccN6gUZ02htATv4cgjKfkvtec nmz5+59DQPI4Es8638m9ygXX2GFt5O+j5yeO7ACZjadEEhxf532t5Pfdyv6kIhGW8MvSFaSCE4Vwr eNfi3uClw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.89 #1 (Red Hat Linux)) id 1ecAJH-00046n-TK; Thu, 18 Jan 2018 13:32:52 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id ACC502029F9F1; Thu, 18 Jan 2018 14:32:48 +0100 (CET) Date: Thu, 18 Jan 2018 14:32:48 +0100 From: Peter Zijlstra To: kan.liang@intel.com Cc: tglx@linutronix.de, mingo@redhat.com, linux-kernel@vger.kernel.org, acme@kernel.org, eranian@google.com, ak@linux.intel.com Subject: Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters Message-ID: <20180118133248.GC2249@hirez.programming.kicks-ass.net> References: <1516042629-387021-1-git-send-email-kan.liang@intel.com> <1516042629-387021-4-git-send-email-kan.liang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516042629-387021-4-git-send-email-kan.liang@intel.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 15, 2018 at 10:57:05AM -0800, kan.liang@intel.com wrote: > From: Kan Liang > > There are a number of free running counters introduced for uncore, which > provide highly valuable information to a wide array of customers. > For example, Skylake Server has IIO free running counters to collect > Input/Output x BW/Utilization. > The precious generic counters could be saved to collect other customer > interested data. > > The free running counter is read-only and always active. Current generic > uncore code does not support this kind of counters. > > Introduce a new index to indicate the free running counters. Only one > index is enough for all free running counters. Because the free running > countes are always active, and the event and free running counter are > always 1:1 mapped. It does not need extra index to indicate the assigned > counter. > > Introduce some rules to encode the event for free running counters. > - The event for free running counter has the same event code 0xff as the > event for fixed counter. > - The umask of the event starts from 0x10. The umask which is less than > 0x10 is reserved for the event of fixed counter. > - The free running counters can be divided into different types > according to the MSR location, bit width or definition. The start > point of the umask for different type has 0x10 offset. > For example, there are three types of IIO free running counters on > Skylake server, IO CLOCKS counters, BANDWIDTH counters and UTILIZATION > counters. > The event code for all free running counters is 0xff. > 'ioclk' is the first counter of IO CLOCKS. IO CLOCKS is the first type > of free running counters, which umask starts from 0x10. > So 'ioclk' is encoded as event=0xff,umask=0x10 > 'bw_in_port2' is the third counter of BANDWIDTH counters. BANDWIDTH is > the second type which umask starts from 0x20. > So 'bw_in_port2' is encoded as event=0xff,umask=0x22. > > Introduce a new data structure to store free running counters related > information for each type. It includes the number of counters, bit > width, base address, offset between counters and offset between boxes. > > Introduce several inline helpers to check index for fixed counter and > free running counter, validate free running counter event, and retrieve > the free running counter information according to box and event. Sorry, none of this makes any sense, what? WTH would all free running counters, which presumably count different things, have the same event code ? And whats the hackery with the umask do? Please rewrite this in comprehensible form and also give rationale for the various choices.