[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200117184249.GB1969121@kroah.com>
Date: Fri, 17 Jan 2020 19:42:49 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: roman.sudarikov@...ux.intel.com, peterz@...radead.org,
mingo@...hat.com, acme@...nel.org, mark.rutland@....com,
alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
namhyung@...nel.org, linux-kernel@...r.kernel.org,
eranian@...gle.com, bgregg@...flix.com, kan.liang@...ux.intel.com,
alexander.antonov@...el.com
Subject: Re: [PATCH v4 2/2] perf x86: Exposing an Uncore unit to PMON for Intel Xeon® server platform
On Fri, Jan 17, 2020 at 09:27:26AM -0800, Andi Kleen wrote:
> > > 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.
Again, you are having to parse a single line of output from sysfs that
contains multiple values, one that will just keep getting bigger and
bigger as time goes on until we run out of space.
One value per file for sysfs, it's been the rule since the beginning.
If there are files that violate this, ugh, it slips through, but as the
submitter is asking for my review, I am going to actually follow the
rules here.
greg k-h
Powered by blists - more mailing lists