From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2F67C33C9E for ; Fri, 17 Jan 2020 17:29:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B8DA7206E6 for ; Fri, 17 Jan 2020 17:29:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729174AbgAQR3B (ORCPT ); Fri, 17 Jan 2020 12:29:01 -0500 Received: from mga07.intel.com ([134.134.136.100]:30201 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726684AbgAQR3A (ORCPT ); Fri, 17 Jan 2020 12:29:00 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2020 09:27:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,330,1574150400"; d="scan'208";a="220796756" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.21]) by fmsmga008.fm.intel.com with ESMTP; 17 Jan 2020 09:27:27 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id E5DBE300DE4; Fri, 17 Jan 2020 09:27:26 -0800 (PST) Date: Fri, 17 Jan 2020 09:27:26 -0800 From: Andi Kleen To: Greg KH Cc: roman.sudarikov@linux.intel.com, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@redhat.com, namhyung@kernel.org, linux-kernel@vger.kernel.org, eranian@google.com, bgregg@netflix.com, kan.liang@linux.intel.com, alexander.antonov@intel.com Subject: Re: [PATCH v4 2/2] perf =?iso-8859-1?Q?x86?= =?iso-8859-1?Q?=3A_Exposing_an_Uncore_unit_to_PMON_for_Intel_Xeon?= =?iso-8859-1?Q?=AE?= server platform Message-ID: <20200117172726.GM302770@tassilo.jf.intel.com> References: <20200117133759.5729-1-roman.sudarikov@linux.intel.com> <20200117133759.5729-3-roman.sudarikov@linux.intel.com> <20200117141944.GC1856891@kroah.com> <20200117162357.GK302770@tassilo.jf.intel.com> <20200117165406.GA1937954@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200117165406.GA1937954@kroah.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Could you suggest how such a 1:N mapping should be expressed instead in > > sysfs? > > I have yet to figure out what it is you all are trying to express here > given a lack of Documentation/ABI/ file :) I thought the example Roman gave was clear. System has multiple dies Each die has 4 pmon ports Each pmon port per die maps to one PCI bus. He mapped it to pmon0-3: list of pci busses indexed by die To be honest the approach doesn't seem unreasonable to me. It's similar e.g. how we express lists of cpus or nodes in sysfs today. -Andi