Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)
On Fri, Apr 17, 2015 at 01:09:54PM -0700, Andi Kleen wrote: On Fri, Apr 17, 2015 at 05:31:26PM +0200, Jiri Olsa wrote: On Wed, Apr 15, 2015 at 01:50:42PM -0700, Sukadev Bhattiprolu wrote: SNIP | | - to blindly follow some poorly constructed vendor format with no |high level structure, that IMHO didn't work very well when OProfile |was written, and misrepresenting it as 'symbolic event names'. | |Take a look at: | | https://download.01.org/perfmon/HSW/Haswell_core_V17.json | |and weep. Evil vendor formats, but to be fair, here is what _we_ have today: perf stat -e r10068,r20036,r40060,r40ac sleep 1 hum, you could also use the 'cpu/event=.../' syntax right? That's even worse -- same hex numbers, just more redundancy. no, it's far more readable then the r format, you can just put in whatevent is in the spec.. event,umask,any etc and dont bother with making r value but I mentioned it just to give the whole picture, I agree that we need the symbolic names support jirka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)
On Wed, Apr 15, 2015 at 01:50:42PM -0700, Sukadev Bhattiprolu wrote:
SNIP
|
| - to add an ABI to support those vendor files
|
| And those are IMHO five good technical reasons to disagree with your
| approach.
|
| My suggestion to resolve the technical objections and lift the NAK
| would be:
|
| - to add the tables to the source code, in a more human readable
|format and (optionally) structure the event names better into a
|higher level hierarchy, than the humungous linear dumps with no
|explanations that you propose - while still supporting the 'raw'
|vendor event names you want to use, for those people who are used
|to them.
|
A bit confused.
Have the JSON files in the tree and generate the C structure during
build?
Or, ditch the JSON files and add something like this in say,
tools/perf/arch/powerpc/util/power8-events.h?
static const struct events power8_events[] = {
[ 0 ] = {
.name = PM_1LPAR_CYC,
.code = 0x1f05e,
.brief_desc = Number of cycles in single lpar mode. All threads in
the core are assigned to the same lpar,,
.public_desc = Number of cycles in single lpar mode.,,
},
If we have the JSON files, would the 'make install' put the JSON files
in ~/.cache/pmu-events or in a standard location?
IIUC the intention is not to have external event data files
but have them compiled into perf binary.. like we could have
JSON with events description under perf source and build it
into 'struct perf_pmu_alias' data duting the build..
the pmu.c alias logic would need a little adjustments,
but it seems doable to me
jirka
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan lijun@freescale.com wrote: Have just sent out a patch considering the previous discussion. http://patchwork.ozlabs.org/patch/462249/ [PATCH] powerpc/defconfig: new way of writing defconfig The ability to merge defconfigs is a feature that's been requested by many people for a long time. Any solution should definitely NOT be PowerPC-only. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 00/17] crypto: talitos - Add support for SEC1
On Fri, Apr 17, 2015 at 04:31:47PM +0200, Christophe Leroy wrote: The purpose of this set of patchs is to add to talitos crypto driver the support for the SEC1 version of the security engine, which is found in mpc885 and mpc8272 processors. v3 is a complete rework of the patchset. Since a kernel can be built with support for both MPC82xx and MPC83xx at the same time, talitos driver shall support both SEC1 and SEC2+ at the same time. Based on cryptodev-2.6 tree All applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: new way of writing defconfigs for freescale's powerpc platforms
-Original Message- From: Bob Cochran [mailto:p...@mindchasers.com] Sent: Thursday, April 16, 2015 8:21 AM To: Wood Scott-B07421; Pan Lijun-B44306 Cc: linuxppc-...@ozlabs.org; Schmitt Richard-B43082 Subject: Re: new way of writing defconfigs for freescale's powerpc platforms On 04/16/2015 12:44 AM, Bob Cochran wrote: On 04/09/2015 06:31 PM, Scott Wood wrote: On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 wrote: Hi Maintainers, We have a proposal for writing the defconfigs for freescale's powperpc platforms in a new way. Can you take a look and provide some feedback? You know currently we have mpc85xx_defconfig, corenet32_defconfig, bsc913x_defconfig, *fman*_defconfig, etc. We are going to extract some common parts from the existing defconfigs, and name it, say, fsl_basic_defconfig. Then, we could create some defconfigs targeting specific features or specific platforms. Say, features specific: kvm_defconfig, fman_defconfig, etc. Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc When we want to make a kernel image for p1 platform, Using the following steps: make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig make What do you think of this new approach? Will you accept this approach? I'm OK with a merge_config approach. I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4. -Scott As you probably know, Freescale makes use of the Yocto Project build system for its SDK and submits patches to the SDK at a public meta-fsl-ppc repo at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ I have seen some kernel related patches in the past come across the Yocto Project site that made use of the Yocto Project kernel tools, which includes a process for maintaining kernel configuration fragments. Here is a link to a patch from a Freescale developer introducing Yocto kernel tool support (description files configuration fragments) to the meta-fsl-ppc repo (FSL QorIQ SDK on Yocto). https://lists.yoctoproject.org/pipermail/meta-freescale/2014- October/010890.html Yes, we do also intend to support this in Yocto and that the fragments will be applied during the build process as part of Yocto recipes and Kernel Features. The first step in doing this is creating the fragments and providing a means to create the platform defconfigs without Yocto. It sounds like the requirements you have could be met with Yocto's existing process. I was hoping to see Freescale continue to move in the direction of using the Yocto kernel tools rather than roll its own solution. There are a number of activities we are doing that will bring us more in the direction of the Yocto kernel tools. But again, Yocto is one way, not the only way. So we intend to support a Makefile approach to building configs (similar to Intel) as well as a Yocto approach to building configs. The Yocto kernel tools make use of description files (*.scc) and configuration fragments (*.cfg). Here is a link to the latest stable Yocto kernel development manual: http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html Bob Rich ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
