Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1436278
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support |
| Date | 2016-07-04 12:20 +0200 |
| Message-ID | <rR98R-4mx-3@gated-at.bofh.it> (permalink) |
| References | <raP9M-1Xm-13@gated-at.bofh.it> <rOYUj-5RL-79@gated-at.bofh.it> <rR98R-4mx-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Jun 28, 2016 at 04:04:59PM +0200, Jan Glauber wrote: > On Tue, Jun 28, 2016 at 11:24:20AM +0100, Will Deacon wrote: > > On Wed, Mar 09, 2016 at 05:21:02PM +0100, Jan Glauber wrote: > > > This patch series provides access to various counters on the ThunderX SOC. > > > > > > For details of the uncore implementation see patch #1. > > > > > > Patches #2-5 add the various ThunderX specific PMUs. > > > > > > As suggested I've put the files under drivers/perf/uncore. I would > > > prefer this location over drivers/bus because not all of the uncore > > > drivers are bus related. > > > > What's the status of these patches? Were you planning to send a new > > version? > > I was half-way through with addressing Mark's review comments when > got side-tracked. > > The principle question these patches raised remains open though in my > opinion, how to determine the socket a device belongs to. > > There is no first-class interface to ask a device or the firmware > which socket the device lives on. > > The options I see are: > A) Using NUMA node information, depends on CONFIG_NUMA > B) Decoding the socket bits of the PCI BAR address > C) Using PCI topology information > > A is what I tried, but I agree that depending on CONFIG_NUMA is not a good > solution. B would be easy but looks not very future-proof. So option C > is what is left... Sorry to go full circle on this, but "depends on NUMA" sounds better than deriving NUMA topology from PCI to me. The only worry I have is if the NUMA information ends up being insufficient in the long-term, and we end up with a mixture of the three options above in order to figure out the PMU topology. As long as you're happy that the PMU:NUMA topology remains 1:1, then I have no objections. The moment you need extra hacks on the side, we should probably drop the NUMA dependency altogether and figure it out some other way. Will
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support Will Deacon <will.deacon@arm.com> - 2016-06-28 13:00 +0200 Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support Will Deacon <will.deacon@arm.com> - 2016-07-04 12:20 +0200
csiph-web