All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>, Andi Kleen <ak@linux.intel.com>
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,
	alexander.antonov@intel.com
Subject: Re: [PATCH v5 3/3] perf x86: Exposing an Uncore unit to PMON for Intel Xeon® server platform
Date: Tue, 11 Feb 2020 14:59:21 -0500	[thread overview]
Message-ID: <25dca8dd-c52d-676d-ffe4-90f3a6ddc915@linux.intel.com> (raw)
In-Reply-To: <20200211185759.GA1941673@kroah.com>



On 2/11/2020 1:57 PM, Greg KH wrote:
> On Tue, Feb 11, 2020 at 10:42:00AM -0800, Andi Kleen wrote:
>> On Tue, Feb 11, 2020 at 09:15:44AM -0800, Greg KH wrote:
>>> On Tue, Feb 11, 2020 at 07:15:49PM +0300, roman.sudarikov@linux.intel.com wrote:
>>>> +static ssize_t skx_iio_mapping_show(struct device *dev,
>>>> +				struct device_attribute *attr, char *buf)
>>>> +{
>>>> +	struct pmu *pmu = dev_get_drvdata(dev);
>>>> +	struct intel_uncore_pmu *uncore_pmu =
>>>> +		container_of(pmu, struct intel_uncore_pmu, pmu);
>>>> +
>>>> +	struct dev_ext_attribute *ea =
>>>> +		container_of(attr, struct dev_ext_attribute, attr);
>>>> +	long die = (long)ea->var;
>>>> +
>>>> +	return sprintf(buf, "0000:%02x\n", skx_iio_stack(uncore_pmu, die));
>>>
>>> If "0000:" is always the "prefix" of the output of this file, why have
>>> it at all as you always know it is there?


I think Roman only test with BIOS configured as single-segment. So he 
hard-code the segment# here.

I'm not sure if Roman can do some test with multiple-segment BIOS. If 
not, I think we should at least print a warning here.

>>>
>>> What is ever going to cause that to change?
>>
>> I think it's just to make it a complete PCI address.
> 
> Is that what this really is?  If so, it's not a "complete" pci address,
> is it?  If it is, use the real pci address please.

I think we don't need a complete PCI address here. The attr is to 
disclose the mapping information between die and PCI BUS. Segment:BUS 
should be good enough.

Thanks,
Kan

> 
>> In theory it might be different on a complex multi node system with
>> custom interconnect and multiple PCI segments, but that would need code
>> changes too.
>>
>> This version of the patchkit only supports standard SKX systems
>> at this point.
> 
> I have no idea what that means, please translate for non-Intel people :)
> 
> greg k-h
> 

  reply	other threads:[~2020-02-11 19:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 16:15 [PATCH v5 0/3] perf x86: Exposing IO stack to IO PMON mapping through sysfs roman.sudarikov
2020-02-11 16:15 ` [PATCH v5 1/3] perf x86: Infrastructure for exposing an Uncore unit to PMON mapping roman.sudarikov
2020-02-11 16:15 ` [PATCH v5 2/3] perf x86: topology max dies for whole system roman.sudarikov
2020-02-11 16:15 ` [PATCH v5 3/3] perf x86: Exposing an Uncore unit to PMON for Intel Xeon® server platform roman.sudarikov
2020-02-11 17:15   ` Greg KH
2020-02-11 18:42     ` Andi Kleen
2020-02-11 18:57       ` Greg KH
2020-02-11 19:59         ` Liang, Kan [this message]
2020-02-11 20:14           ` Greg KH
2020-02-12 17:31             ` Sudarikov, Roman
2020-02-12 20:58               ` Liang, Kan
2020-02-12 22:56                 ` Greg KH
2020-02-13 12:36                   ` Sudarikov, Roman
2020-02-13 13:08                     ` Greg KH
2020-02-11 17:18   ` Greg KH
2020-02-11 20:09   ` Liang, Kan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25dca8dd-c52d-676d-ffe4-90f3a6ddc915@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.antonov@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bgregg@netflix.com \
    --cc=eranian@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=roman.sudarikov@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.