From: Andi K. <an...@fi...> - 2013-07-24 23:23:26
|
From: Andi Kleen <ak...@li...> Thanks to Sanjay Patel for noticing the missing ULT number. Signed-off-by: Andi Kleen <ak...@li...> --- libop/op_hw_specific.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libop/op_hw_specific.h b/libop/op_hw_specific.h index 7b9c97c..6ae19bc 100644 --- a/libop/op_hw_specific.h +++ b/libop/op_hw_specific.h @@ -145,6 +145,8 @@ static inline op_cpu op_cpu_specific_type(op_cpu cpu_type) case 0x3e: return CPU_IVYBRIDGE; case 0x3c: + case 0x3f: + case 0x45: case 0x46: case 0x47: return CPU_HASWELL; -- 1.8.3.1 |
From: Maynard J. <may...@us...> - 2013-07-25 15:38:27
|
On 07/24/2013 05:48 PM, Andi Kleen wrote: > From: Andi Kleen <ak...@li...> > > Thanks to Sanjay Patel for noticing the missing ULT number. OK, Andi, I'll put out an RC2 that has this fix (I know of at least one other problem that should be fixed, too). Before rolling out RC2, I would like to get some more testing feedback on RC1 -- from any community members, but especially from my fellow maintainers on cc. Thanks. -Maynard > > Signed-off-by: Andi Kleen <ak...@li...> > --- > libop/op_hw_specific.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libop/op_hw_specific.h b/libop/op_hw_specific.h > index 7b9c97c..6ae19bc 100644 > --- a/libop/op_hw_specific.h > +++ b/libop/op_hw_specific.h > @@ -145,6 +145,8 @@ static inline op_cpu op_cpu_specific_type(op_cpu cpu_type) > case 0x3e: > return CPU_IVYBRIDGE; > case 0x3c: > + case 0x3f: > + case 0x45: > case 0x46: > case 0x47: > return CPU_HASWELL; > |
From: Maynard J. <may...@us...> - 2013-07-25 19:38:13
|
On 07/25/2013 10:07 AM, Maynard Johnson wrote: > On 07/24/2013 05:48 PM, Andi Kleen wrote: >> From: Andi Kleen <ak...@li...> >> >> Thanks to Sanjay Patel for noticing the missing ULT number. > > OK, Andi, I'll put out an RC2 that has this fix (I know of at least one other problem that should be fixed, too). Before rolling out RC2, I would like to get some more testing feedback on RC1 -- from any community members, but especially from my fellow maintainers on cc. Oops! Didn't mean to leave you out of the fun, Will. ;-) -Maynard > > Thanks. > -Maynard >> >> Signed-off-by: Andi Kleen <ak...@li...> >> --- >> libop/op_hw_specific.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/libop/op_hw_specific.h b/libop/op_hw_specific.h >> index 7b9c97c..6ae19bc 100644 >> --- a/libop/op_hw_specific.h >> +++ b/libop/op_hw_specific.h >> @@ -145,6 +145,8 @@ static inline op_cpu op_cpu_specific_type(op_cpu cpu_type) >> case 0x3e: >> return CPU_IVYBRIDGE; >> case 0x3c: >> + case 0x3f: >> + case 0x45: >> case 0x46: >> case 0x47: >> return CPU_HASWELL; >> > |
From: William C. <wc...@re...> - 2013-07-25 21:32:28
|
On 07/25/2013 03:37 PM, Maynard Johnson wrote: > On 07/25/2013 10:07 AM, Maynard Johnson wrote: >> On 07/24/2013 05:48 PM, Andi Kleen wrote: >>> From: Andi Kleen <ak...@li...> >>> >>> Thanks to Sanjay Patel for noticing the missing ULT number. >> >> OK, Andi, I'll put out an RC2 that has this fix (I know of at least one other problem that should be fixed, too). Before rolling out RC2, I would like to get some more testing feedback on RC1 -- from any community members, but especially from my fellow maintainers on cc. > Oops! Didn't mean to leave you out of the fun, Will. ;-) > > -Maynard No problem, I saw the earlier email and included those additional entries in the testsuite. -Will >> >> Thanks. >> -Maynard >>> >>> Signed-off-by: Andi Kleen <ak...@li...> >>> --- >>> libop/op_hw_specific.h | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/libop/op_hw_specific.h b/libop/op_hw_specific.h >>> index 7b9c97c..6ae19bc 100644 >>> --- a/libop/op_hw_specific.h >>> +++ b/libop/op_hw_specific.h >>> @@ -145,6 +145,8 @@ static inline op_cpu op_cpu_specific_type(op_cpu cpu_type) >>> case 0x3e: >>> return CPU_IVYBRIDGE; >>> case 0x3c: >>> + case 0x3f: >>> + case 0x45: >>> case 0x46: >>> case 0x47: >>> return CPU_HASWELL; >>> >> > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: Will D. <wil...@ar...> - 2013-07-26 08:39:13
|
On Thu, Jul 25, 2013 at 10:31:29PM +0100, William Cohen wrote: > On 07/25/2013 03:37 PM, Maynard Johnson wrote: > > On 07/25/2013 10:07 AM, Maynard Johnson wrote: > >> On 07/24/2013 05:48 PM, Andi Kleen wrote: > >>> From: Andi Kleen <ak...@li...> > >>> > >>> Thanks to Sanjay Patel for noticing the missing ULT number. > >> > >> OK, Andi, I'll put out an RC2 that has this fix (I know of at least one other problem that should be fixed, too). Before rolling out RC2, I would like to get some more testing feedback on RC1 -- from any community members, but especially from my fellow maintainers on cc. > > Oops! Didn't mean to leave you out of the fun, Will. ;-) > > > > -Maynard > > No problem, > > I saw the earlier email and included those additional entries in the testsuite. Wrong Will :) I guess we should be WillC and WillD to avoid confusion. Will |
From: Will D. <wil...@ar...> - 2013-07-26 16:32:03
|
Hi Maynard, On Thu, Jul 25, 2013 at 08:37:28PM +0100, Maynard Johnson wrote: > On 07/25/2013 10:07 AM, Maynard Johnson wrote: > > On 07/24/2013 05:48 PM, Andi Kleen wrote: > >> From: Andi Kleen <ak...@li...> > >> > >> Thanks to Sanjay Patel for noticing the missing ULT number. > > > > OK, Andi, I'll put out an RC2 that has this fix (I know of at least one other problem that should be fixed, too). Before rolling out RC2, I would like to get some more testing feedback on RC1 -- from any community members, but especially from my fellow maintainers on cc. > Oops! Didn't mean to leave you out of the fun, Will. ;-) Ok, all looks good on ARM (Cortex-A15) except that the minimum event period for the default event (CPU_CYCLES) is too low, so running operf -g without any additional arguments grinds everything to a halt. There's a patch below to sort that out. Cheers, Will --->8 >From f0b0b77abebfe213954366e416efbe753647dc82 Mon Sep 17 00:00:00 2001 From: Will Deacon <wil...@ar...> Date: Fri, 26 Jul 2013 17:26:07 +0100 Subject: [PATCH] ARM: events: increase minimum cycle period to 100k On ARM, we intentionally leave the minimum event counters low since the performance profile of the cores can vary dramatically between CPUs and their implementations. However, since the default event is CPU_CYCLES, it's best to err on the side of caution and raise the limit to something more realistic so we don't lock-up on the unsuspecting user (as opposed to somebody passing an explicit event period). This patch raises the CPU_CYCLES minimum event count to 100k on ARM. Signed-off-by: Will Deacon <wil...@ar...> --- events/arm/armv7-common/events | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/events/arm/armv7-common/events b/events/arm/armv7-common/events index 0b6ed45..c83b2b7 100644 --- a/events/arm/armv7-common/events +++ b/events/arm/armv7-common/events @@ -33,4 +33,4 @@ event:0x1B counters:1,2,3,4,5,6 um:zero minimum:500 name:INST_SPEC : Instruction event:0x1C counters:1,2,3,4,5,6 um:zero minimum:500 name:TTBR_WRITE_RETIRED : Write to TTBR architecturally executed, condition code pass event:0x1D counters:1,2,3,4,5,6 um:zero minimum:500 name:BUS_CYCLES : Bus cycle -event:0xFF counters:0 um:zero minimum:500 name:CPU_CYCLES : CPU cycle +event:0xFF counters:0 um:zero minimum:100000 name:CPU_CYCLES : CPU cycle -- 1.8.2.2 |
From: Maynard J. <may...@us...> - 2013-07-29 15:36:36
|
On 07/26/2013 11:31 AM, Will Deacon wrote: > Hi Maynard, > > On Thu, Jul 25, 2013 at 08:37:28PM +0100, Maynard Johnson wrote: >> On 07/25/2013 10:07 AM, Maynard Johnson wrote: >>> On 07/24/2013 05:48 PM, Andi Kleen wrote: >>>> From: Andi Kleen <ak...@li...> >>>> >>>> Thanks to Sanjay Patel for noticing the missing ULT number. >>> >>> OK, Andi, I'll put out an RC2 that has this fix (I know of at least one other problem that should be fixed, too). Before rolling out RC2, I would like to get some more testing feedback on RC1 -- from any community members, but especially from my fellow maintainers on cc. >> Oops! Didn't mean to leave you out of the fun, Will. ;-) > > Ok, all looks good on ARM (Cortex-A15) except that the minimum event period > for the default event (CPU_CYCLES) is too low, so running operf -g without > any additional arguments grinds everything to a halt. > > There's a patch below to sort that out. Thanks, Will. Patch applied. -Maynard > > Cheers, > > Will > > --->8 > > From f0b0b77abebfe213954366e416efbe753647dc82 Mon Sep 17 00:00:00 2001 > From: Will Deacon <wil...@ar...> > Date: Fri, 26 Jul 2013 17:26:07 +0100 > Subject: [PATCH] ARM: events: increase minimum cycle period to 100k > > On ARM, we intentionally leave the minimum event counters low since > the performance profile of the cores can vary dramatically between CPUs > and their implementations. > > However, since the default event is CPU_CYCLES, it's best to err on the > side of caution and raise the limit to something more realistic so we > don't lock-up on the unsuspecting user (as opposed to somebody passing > an explicit event period). > > This patch raises the CPU_CYCLES minimum event count to 100k on ARM. > > Signed-off-by: Will Deacon <wil...@ar...> > --- > events/arm/armv7-common/events | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/events/arm/armv7-common/events b/events/arm/armv7-common/events > index 0b6ed45..c83b2b7 100644 > --- a/events/arm/armv7-common/events > +++ b/events/arm/armv7-common/events > @@ -33,4 +33,4 @@ event:0x1B counters:1,2,3,4,5,6 um:zero minimum:500 name:INST_SPEC : Instruction > event:0x1C counters:1,2,3,4,5,6 um:zero minimum:500 name:TTBR_WRITE_RETIRED : Write to TTBR architecturally executed, condition code pass > event:0x1D counters:1,2,3,4,5,6 um:zero minimum:500 name:BUS_CYCLES : Bus cycle > > -event:0xFF counters:0 um:zero minimum:500 name:CPU_CYCLES : CPU cycle > +event:0xFF counters:0 um:zero minimum:100000 name:CPU_CYCLES : CPU cycle > |
From: Maynard J. <may...@us...> - 2013-07-26 16:57:46
|
On 07/26/2013 11:31 AM, Will Deacon wrote: > Hi Maynard, > > On Thu, Jul 25, 2013 at 08:37:28PM +0100, Maynard Johnson wrote: >> On 07/25/2013 10:07 AM, Maynard Johnson wrote: >>> On 07/24/2013 05:48 PM, Andi Kleen wrote: >>>> From: Andi Kleen <ak...@li...> >>>> >>>> Thanks to Sanjay Patel for noticing the missing ULT number. >>> >>> OK, Andi, I'll put out an RC2 that has this fix (I know of at least one other problem that should be fixed, too). Before rolling out RC2, I would like to get some more testing feedback on RC1 -- from any community members, but especially from my fellow maintainers on cc. >> Oops! Didn't mean to leave you out of the fun, Will. ;-) > > Ok, all looks good on ARM (Cortex-A15) except that the minimum event period > for the default event (CPU_CYCLES) is too low, so running operf -g without > any additional arguments grinds everything to a halt. > > There's a patch below to sort that out. Thanks for the ARM testing, Will. *ATTENTION oprofile community*: So far, there are only three small changes to make in the 0.9.9-rc1: - New model number of Haswell - ocount fix for ppc64 events that have "GRP" in the name - The ARM CPU_CYCLES default count value I'm considering committing these changes and going straight to 0.9.9 GA, probably early next week. I encourage one and all to try out the RC1 as soon as possible and let me know if you have any concerns. Thanks. -Maynard > > Cheers, > > Will > > --->8 > > From f0b0b77abebfe213954366e416efbe753647dc82 Mon Sep 17 00:00:00 2001 > From: Will Deacon <wil...@ar...> > Date: Fri, 26 Jul 2013 17:26:07 +0100 > Subject: [PATCH] ARM: events: increase minimum cycle period to 100k > > On ARM, we intentionally leave the minimum event counters low since > the performance profile of the cores can vary dramatically between CPUs > and their implementations. > > However, since the default event is CPU_CYCLES, it's best to err on the > side of caution and raise the limit to something more realistic so we > don't lock-up on the unsuspecting user (as opposed to somebody passing > an explicit event period). > > This patch raises the CPU_CYCLES minimum event count to 100k on ARM. > > Signed-off-by: Will Deacon <wil...@ar...> > --- > events/arm/armv7-common/events | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/events/arm/armv7-common/events b/events/arm/armv7-common/events > index 0b6ed45..c83b2b7 100644 > --- a/events/arm/armv7-common/events > +++ b/events/arm/armv7-common/events > @@ -33,4 +33,4 @@ event:0x1B counters:1,2,3,4,5,6 um:zero minimum:500 name:INST_SPEC : Instruction > event:0x1C counters:1,2,3,4,5,6 um:zero minimum:500 name:TTBR_WRITE_RETIRED : Write to TTBR architecturally executed, condition code pass > event:0x1D counters:1,2,3,4,5,6 um:zero minimum:500 name:BUS_CYCLES : Bus cycle > > -event:0xFF counters:0 um:zero minimum:500 name:CPU_CYCLES : CPU cycle > +event:0xFF counters:0 um:zero minimum:100000 name:CPU_CYCLES : CPU cycle > |
From: Andi K. <an...@fi...> - 2013-07-26 19:20:55
|
> *ATTENTION oprofile community*: So far, there are only three small changes to make in the 0.9.9-rc1: > - New model number of Haswell > - ocount fix for ppc64 events that have "GRP" in the name > - The ARM CPU_CYCLES default count value I did some more testing. Things generally work. The only nit I noticed was that operf does complain about lost samples when some files could not be found, which seems drastic. But may not be important enough to fix now. -Andi |
From: Robert R. <rr...@ke...> - 2013-07-29 14:10:30
|
Maynard, On 26.07.13 11:57:22, Maynard Johnson wrote: > *ATTENTION oprofile community*: So far, there are only three small changes to make in the 0.9.9-rc1: > - New model number of Haswell > - ocount fix for ppc64 events that have "GRP" in the name > - The ARM CPU_CYCLES default count value > > I'm considering committing these changes and going straight to 0.9.9 > GA, probably early next week. I encourage one and all to try out > the RC1 as soon as possible and let me know if you have any > concerns. I found the following while building the documentation: XML_CATALOG_FILES=xsl/catalog.xml xsltproc --nonet -o oprofile.html --stringparam version 0.9.9git .../oprofile/doc/xsl/xhtml.xsl .../oprofile/doc/oprofile.xml ERROR: xref linking to controlling has no generated link text. Error: no ID for constraint linkend: controlling. ERROR: xref linking to controlling has no generated link text. Error: no ID for constraint linkend: controlling. Otherwise my tests run successfully. -Robert |
From: Robert R. <rr...@ke...> - 2013-07-29 14:50:14
|
On 29.07.13 16:10:14, Robert Richter wrote: > XML_CATALOG_FILES=xsl/catalog.xml xsltproc --nonet -o oprofile.html --stringparam version 0.9.9git .../oprofile/doc/xsl/xhtml.xsl .../oprofile/doc/oprofile.xml > ERROR: xref linking to controlling has no generated link text. > Error: no ID for constraint linkend: controlling. > ERROR: xref linking to controlling has no generated link text. > Error: no ID for constraint linkend: controlling. This is caused by <xref linkend="controlling" /> in doc/oprofile.xml. The patch below fixes this. -Robert >From 8e08c4b980ad7a69baddb4ede9979227e2a73772 Mon Sep 17 00:00:00 2001 From: Robert Richter <rr...@ke...> Date: Mon, 29 Jul 2013 16:39:40 +0200 Subject: [PATCH] oprofile, doc: Fix missing xrefs This patch fixes the following errors: $ XML_CATALOG_FILES=xsl/catalog.xml xsltproc --nonet -o oprofile.html --stringparam version 0.9.9git .../oprofile/doc/xsl/xhtml.xsl .../oprofile/doc/oprofile.xml ERROR: xref linking to controlling has no generated link text. Error: no ID for constraint linkend: controlling. ERROR: xref linking to controlling has no generated link text. Error: no ID for constraint linkend: controlling. Signed-off-by: Robert Richter <rr...@ke...> --- doc/oprofile.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/oprofile.xml b/doc/oprofile.xml index ab2de7b..d6ce73d 100644 --- a/doc/oprofile.xml +++ b/doc/oprofile.xml @@ -670,14 +670,14 @@ This section gives a brief description of the available OProfile utilities and t <varlistentry> <term><filename>operf</filename></term> <listitem><para> - This is the recommended program for collecting profile data, discussed in <xref linkend="controlling" />. + This is the recommended program for collecting profile data, discussed in <xref linkend="controlling-operf" />. </para></listitem> </varlistentry> <varlistentry> <term><filename>opcontrol</filename></term> <listitem><para> - Used for controlling OProfile data collection in legacy mode, discussed in <xref linkend="controlling" />. + Used for controlling OProfile data collection in legacy mode, discussed in <xref linkend="controlling-daemon" />. </para></listitem> </varlistentry> -- 1.8.3.2 |
From: Maynard J. <may...@us...> - 2013-07-29 15:33:19
|
On 07/29/2013 09:49 AM, Robert Richter wrote: > On 29.07.13 16:10:14, Robert Richter wrote: >> XML_CATALOG_FILES=xsl/catalog.xml xsltproc --nonet -o oprofile.html --stringparam version 0.9.9git .../oprofile/doc/xsl/xhtml.xsl .../oprofile/doc/oprofile.xml >> ERROR: xref linking to controlling has no generated link text. >> Error: no ID for constraint linkend: controlling. >> ERROR: xref linking to controlling has no generated link text. >> Error: no ID for constraint linkend: controlling. > > This is caused by > > <xref linkend="controlling" /> > > in doc/oprofile.xml. > > The patch below fixes this. > > -Robert > > > From 8e08c4b980ad7a69baddb4ede9979227e2a73772 Mon Sep 17 00:00:00 2001 > From: Robert Richter <rr...@ke...> > Date: Mon, 29 Jul 2013 16:39:40 +0200 > Subject: [PATCH] oprofile, doc: Fix missing xrefs > > This patch fixes the following errors: > > $ XML_CATALOG_FILES=xsl/catalog.xml xsltproc --nonet -o oprofile.html > --stringparam version 0.9.9git .../oprofile/doc/xsl/xhtml.xsl > .../oprofile/doc/oprofile.xml > ERROR: xref linking to controlling has no generated link text. > Error: no ID for constraint linkend: controlling. > ERROR: xref linking to controlling has no generated link text. > Error: no ID for constraint linkend: controlling. > > Signed-off-by: Robert Richter <rr...@ke...> Thanks, Robert! Patch applied. -Maynard > --- > doc/oprofile.xml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/doc/oprofile.xml b/doc/oprofile.xml > index ab2de7b..d6ce73d 100644 > --- a/doc/oprofile.xml > +++ b/doc/oprofile.xml > @@ -670,14 +670,14 @@ This section gives a brief description of the available OProfile utilities and t > <varlistentry> > <term><filename>operf</filename></term> > <listitem><para> > - This is the recommended program for collecting profile data, discussed in <xref linkend="controlling" />. > + This is the recommended program for collecting profile data, discussed in <xref linkend="controlling-operf" />. > </para></listitem> > </varlistentry> > > <varlistentry> > <term><filename>opcontrol</filename></term> > <listitem><para> > - Used for controlling OProfile data collection in legacy mode, discussed in <xref linkend="controlling" />. > + Used for controlling OProfile data collection in legacy mode, discussed in <xref linkend="controlling-daemon" />. > </para></listitem> > </varlistentry> > |
From: Maynard J. <may...@us...> - 2013-07-29 15:51:03
|
On 07/24/2013 05:48 PM, Andi Kleen wrote: > From: Andi Kleen <ak...@li...> > > Thanks to Sanjay Patel for noticing the missing ULT number. > > Signed-off-by: Andi Kleen <ak...@li...> Thanks, Andi. Patch applied. -Maynard > --- > libop/op_hw_specific.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libop/op_hw_specific.h b/libop/op_hw_specific.h > index 7b9c97c..6ae19bc 100644 > --- a/libop/op_hw_specific.h > +++ b/libop/op_hw_specific.h > @@ -145,6 +145,8 @@ static inline op_cpu op_cpu_specific_type(op_cpu cpu_type) > case 0x3e: > return CPU_IVYBRIDGE; > case 0x3c: > + case 0x3f: > + case 0x45: > case 0x46: > case 0x47: > return CPU_HASWELL; > |