| Message ID | 1426757313-20981-2-git-send-email-maddy@linux.vnet.ibm.com |
|---|---|
| State | Changes Requested |
| Headers | show |
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes: > +/* > + * Power8 has Nest Instrumentation support with which per-chip > + * utilisation metrics like memory bandwidth, IO bandwidth and > + * many other component metrics can be obtained. These Nest > + * counters can be programmed via scoms or HW PORE Engine, > + * called PORE_SLW_IMA. > + * > + * In the Linux kernel side, have used intel's "uncore" framework > + * to plug the Power8 nest instrumentation support. For the > + * consistency, have used "uncore" for in the variable/file names > + * here for services provided by opal. > + * Why not just call it nest_pmu everywhere? I can't see anywhere that's really forcing us to use uncore terminology.
On Wed, 2015-04-22 at 11:44 +1000, Stewart Smith wrote: > Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes: > > +/* > > + * Power8 has Nest Instrumentation support with which per-chip > > + * utilisation metrics like memory bandwidth, IO bandwidth and > > + * many other component metrics can be obtained. These Nest > > + * counters can be programmed via scoms or HW PORE Engine, > > + * called PORE_SLW_IMA. > > + * > > + * In the Linux kernel side, have used intel's "uncore" framework > > + * to plug the Power8 nest instrumentation support. For the > > + * consistency, have used "uncore" for in the variable/file names > > + * here for services provided by opal. > > + * > > Why not just call it nest_pmu everywhere? I can't see anywhere that's > really forcing us to use uncore terminology. +1 I'm not entirely convinced it makes sense to use the uncore stuff in Linux, but it definitely doesn't make sense to propagate the name down into skiboot. cheers
On Wednesday 22 April 2015 07:27 AM, Michael Ellerman wrote: > On Wed, 2015-04-22 at 11:44 +1000, Stewart Smith wrote: >> Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes: >>> +/* >>> + * Power8 has Nest Instrumentation support with which per-chip >>> + * utilisation metrics like memory bandwidth, IO bandwidth and >>> + * many other component metrics can be obtained. These Nest >>> + * counters can be programmed via scoms or HW PORE Engine, >>> + * called PORE_SLW_IMA. >>> + * >>> + * In the Linux kernel side, have used intel's "uncore" framework >>> + * to plug the Power8 nest instrumentation support. For the >>> + * consistency, have used "uncore" for in the variable/file names >>> + * here for services provided by opal. >>> + * >> Why not just call it nest_pmu everywhere? I can't see anywhere that's >> really forcing us to use uncore terminology. > +1 > > I'm not entirely convinced it makes sense to use the uncore stuff in Linux, but > it definitely doesn't make sense to propagate the name down into skiboot. > > cheers > The latest update is that, we have a new draft catalog lid released. Based on that, I am developing feature detection code. I will also make changes suggested. Thanks for review Maddy
On Wednesday 22 April 2015 07:27 AM, Michael Ellerman wrote: > On Wed, 2015-04-22 at 11:44 +1000, Stewart Smith wrote: >> Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes: >>> +/* >>> + * Power8 has Nest Instrumentation support with which per-chip >>> + * utilisation metrics like memory bandwidth, IO bandwidth and >>> + * many other component metrics can be obtained. These Nest >>> + * counters can be programmed via scoms or HW PORE Engine, >>> + * called PORE_SLW_IMA. >>> + * >>> + * In the Linux kernel side, have used intel's "uncore" framework >>> + * to plug the Power8 nest instrumentation support. For the >>> + * consistency, have used "uncore" for in the variable/file names >>> + * here for services provided by opal. >>> + * >> Why not just call it nest_pmu everywhere? I can't see anywhere that's >> really forcing us to use uncore terminology. > +1 > > I'm not entirely convinced it makes sense to use the uncore stuff in Linux, but > it definitely doesn't make sense to propagate the name down into skiboot. > > cheers > FYI.. I am redesigning to make each nest unit as a separate PMU in the kernel side (to drop the uncore stuff). Will send out the new patch set for both opal and kernel side soon. Thanks for review. Maddy
diff --git a/include/uncore.h b/include/uncore.h new file mode 100644 index 0000000..c1c6bed --- /dev/null +++ b/include/uncore.h @@ -0,0 +1,102 @@ +/* Copyright 2015 IBM Corp. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + * implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +#ifndef __UNCORE_H +#define __UNCORE_H + +/* + * Power8 has Nest Instrumentation support with which per-chip + * utilisation metrics like memory bandwidth, IO bandwidth and + * many other component metrics can be obtained. These Nest + * counters can be programmed via scoms or HW PORE Engine, + * called PORE_SLW_IMA. + * + * In the Linux kernel side, have used intel's "uncore" framework + * to plug the Power8 nest instrumentation support. For the + * consistency, have used "uncore" for in the variable/file names + * here for services provided by opal. + * + * PORE_SLW_IMA: + * PORE_SLW_IMA is a piece of software that runs on PORE Engine. + * This programs the nest counter and moves counter values to + * per chip HOMER region in a fixed offset for each unit. Engine + * has a control block structure for communication with Hyperviosr. + */ + +/* + * Control Block structure offset in HOMER IMA Region + */ +#define CB_STRUCT_OFFSET 0x39FC00 + +/* + * Control Block Structure: + * + * Name Producer Consumer Values Desc + * IMARunStatus IMA Code Hypervisor 0 Initializing + * 1 Running + * 2 Paused + * + * IMACommand Hypervisor IMA Code 0 NOP + * 1 Resume + * 2 Pause + * 3 Clear and Restart + * + * IMACollection Hypervisor IMA Code 0 128us + * Speed 1 256us + * 2 1ms + * 3 4ms + * 4 16ms + * 5 64ms + * 6 256ms + * 7 1000ms + */ +struct uncore_cb +{ + uint64_t uncore_run_status; + uint64_t uncore_command; + uint64_t uncore_collection_speed; +}; + +/* + * PORE_SLW_IMA reserved memory (in HOMER region) + */ +#define SLW_IMA_OFFSET 0x00320000 +#define SLW_IMA_TOTAL_SIZE 0x80000 + +/* + * Counter Storage size (exposed as part of DT) + */ +#define SLW_IMA_SIZE 0x10000 + +/* + * PTS Scoms and values + */ +#define IMA_PTS_SCOM 0x00068009 +#define IMA_PTS_ENABLE 0x00F0000000000000 +#define IMA_PTS_DISABLE 0x00E0000000000000 +#define IMA_PTS_START 0x1 +#define IMA_PTS_STOP 0 +#define IMA_PTS_ERROR -1 + +/* + * POWER8 Memory Controllers + */ +#define P8_IMA_MCS_COUNT 0x4 + +extern int pore_slw_ima_scom (uint32_t , uint32_t ); +extern void uncore_init(void); + +#endif /* __UNCORE_H__ */
Patch adds the data structures and macros needed for Nest instrumentation support. Patch creates new file in include dir called "uncore.h" which contains all the macros and structure. Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> --- include/uncore.h | 102 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 include/uncore.h