Corey Ashford | 1 Apr 2008 01:24
Picon
Favicon

perfmon2 code restructuring news

Hi Stephane,

This is great news!  I will start the testing process on POWER soon.

Assuming the testing goes relatively smoothly, do you have a feeling as
to when you'd be able to post the first of the patches to the LKML
mailing list?

Thanks,

- Corey

> Hello,
> 
> I have spent most of last week restructuring the current perfmon2
> kernel code base to make it easier to isolate
> features. That should make it easier for the merge with mainline given
> that LKML people would like to receive
> small patches each adding one feature at a time.
> 
> I have created a bunch of new files under perfmon/, each one
> implementing a feature or logically similar set of
> features. Similarly, I have also restructured the header files to
> separate the generic interface definition in
> perfmon.h from all the stuff needed by the kernel implementation, now
> in perfmon_kern.h. This model is replicated
> for each arch. Perfmon_const.h is gone.
> 
> I have also completely restructured the interrupt handling code in
> perfmon_intr.c. It is now much more readable
(Continue reading)

Arnd Bergmann | 1 Apr 2008 02:28
X-Face
Picon
Gravatar

perfmon2 code restructuring news

stephane eranian wrote:
>  I have spent most of last week restructuring the current perfmon2
>  kernel code base to make it easier to isolate
>  features. That should make it easier for the merge with mainline given
>  that LKML people would like to receive
>  small patches each adding one feature at a time.

Ah, this looks really good. I haven't really followed the perfmon2
progress over the last few releases. What is your plan for submission
to upstream inclusion? I guess if you want to have a chance of getting
it into 2.6.26, now would be the time to post the patches.
I can certainly offer some help getting it into shape for inclusion
if you're interested.

At some point I think you'll need a rebased git tree that contains
the changesets in exactly the way you want them to be merged,
and then you keep changing those patches, instead of adding new
changes on top.

>  I have created a bunch of new files under perfmon/, each one
>  implementing a feature or logically similar set of
>  features. Similarly, I have also restructured the header files to
>  separate the generic interface definition in
>  perfmon.h from all the stuff needed by the kernel implementation, now
>  in perfmon_kern.h. This model is replicated
>  for each arch. Perfmon_const.h is gone.

I looked at the file structure now, and I think it can be done a little
bit better still:

(Continue reading)

TakashiYamamoto | 1 Apr 2008 04:31
Picon

Re: [PATCH 2/7] : Add cell_spe_follow flag to the context flags

Hello,

> >  > Why do you need to expose this Cell-specific feature into generic code?
> >  >
> >  > Can't you hide this inside the arch code by using the pfm_arch_*() callbacks?
> >
> >  No.
> >  In this patch, I want to avoid setting TIF_PERFMON_CTXSW to the task flag
> >  when cell_spe_follow flag is set.
> >  I couln't hide this change in pfmon_arch_load_context(),
> >  because it is called before set_task_thread_flag().
> >
> Ok, I see your problem now.
> 
> We have 2 solutions:
>    - move pfm_arch_load_context() AFTER the TIF_PERFMON_CTXSW
>    - add a generic flag (context_flags) that pfm_arch_load_context()
> can set to tell the generic code NOT to set TIF_PERFMON_CTXSW
> 
> I'd rather not move pfm_arch_load_context() because there would be
> more  code to undo if it ever fails.
> 
> The 2nd solution is not too pretty either because it relies on the
> position of pfm_arch_load_context(). However, we could move
> setting that flag to pfm_arch_create_context() given that you've added
> the context-level flag for SPE_FOLLOW. Could you try that?

How about this?
Is this the change which you expected?

(Continue reading)

Feng Chen | 1 Apr 2008 05:32
Picon

Perfmon2 does not work correctly for Core Quad

Hello,

  we just purchased a Dell PowerEdge 1900 machine with two Intel Core
Quad 5355 processors, and the OS is RHAS5. We installed the perfmon2
(080225) on the machine. The compilation and installation has no
problem, but we met a problem, only seven events could be listed using
"pfmon -l", they are:

UNHALTED_CORE_CYCLES
INSTRUCTIONS_RETIRED
UNHALTED_REFERENCE_CYCLES
LAST_LEVEL_CACHE_REFERENCES
LAST_LEVEL_CACHE_MISSES
BRANCH_INSTRUCTIONS_RETIRED
MISPREDICTED_BRANCH_RETIRED

pfmon -I shows the CPU has been detected correctly. We also tried
older version 071017 and 070209. We also tried to install it in a
64-bit version of RHAS5, it does work either. Appreciate it if you can
give some hints to solve the problem.

Thanks a lot.

Feng

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
(Continue reading)

stephane eranian | 1 Apr 2008 08:05

Re: Perfmon2 does not work correctly for Core Quad

Hello,

For some reason, pfmon and libpfm are defaulting to the architected PMU.
Could you send me the output from /proc/cpuinfo (one CPU is enough)?

Thanks.

On Tue, Apr 1, 2008 at 5:32 AM, Feng Chen <fchen1978 <at> gmail.com> wrote:
> Hello,
>
>   we just purchased a Dell PowerEdge 1900 machine with two Intel Core
>  Quad 5355 processors, and the OS is RHAS5. We installed the perfmon2
>  (080225) on the machine. The compilation and installation has no
>  problem, but we met a problem, only seven events could be listed using
>  "pfmon -l", they are:
>
>  UNHALTED_CORE_CYCLES
>  INSTRUCTIONS_RETIRED
>  UNHALTED_REFERENCE_CYCLES
>  LAST_LEVEL_CACHE_REFERENCES
>  LAST_LEVEL_CACHE_MISSES
>  BRANCH_INSTRUCTIONS_RETIRED
>  MISPREDICTED_BRANCH_RETIRED
>
>  pfmon -I shows the CPU has been detected correctly. We also tried
>  older version 071017 and 070209. We also tried to install it in a
>  64-bit version of RHAS5, it does work either. Appreciate it if you can
>  give some hints to solve the problem.
>
>  Thanks a lot.
(Continue reading)

stephane eranian | 1 Apr 2008 09:19

Re: Problems encountered on Pentium 4

Hello,

2008/3/27 J K Rai <jk.anurag <at> yahoo.com>:
>
> Problems encountered while using two events together:
> ========================================================
> ******************************************************************************************************
> The events mentioned first gets the count values while the next one remains
> zero always as shown below
> ******************************************************************************************************
>
> session output:
> ==============
> ashwin <at> SUSE-HT:~> pfmon -ePAGE_WALK_TYPE:DTMISS,PAGE_WALK_TYPE:ITMISS ls
> /dev/null
> /dev/null
> 967 PAGE_WALK_TYPE:DTMISS
>   0 PAGE_WALK_TYPE:ITMISS
>
Could you try measuring ONLY the second event instead? It may be a bug
in libpfm assignment of events to counters. That would
not surprise me on Pentium 4, it is so complicated.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Feng Chen | 1 Apr 2008 09:47
Picon

Re: Perfmon2 does not work correctly for Core Quad

hello,

Thanks for response.
/proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU           X5355   <at>  2.66GHz
stepping        : 11
cpu MHz         : 2660.081
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2
ssse3 cx16 xtpr dca lahf_lm
bogomips        : 5429.34
(Continue reading)

stephane eranian | 1 Apr 2008 10:25

Re: Perfmon2 does not work correctly for Core Quad

Hello,

On Tue, Apr 1, 2008 at 9:47 AM, Feng Chen <fchen1978 <at> gmail.com> wrote:
> hello,
>
>  Thanks for response.
>  /proc/cpuinfo
>
>  processor       : 0
>  vendor_id       : GenuineIntel
>  cpu family      : 6
>  model           : 15

That part looks good. Intel Core should be detected here
>  ------------------------------------
>  The output of "pfmon -I" is:
>
>  detected host CPUs:  8-way 2660MHz/4.0MB -- Intel(R) Xeon(R) CPU X5355
>   <at>  2.66GHz (stepping 11)
>  detected PMU model: Intel architectural PMU

That's not good. Should be Intel Core. Pfmon says it has support for
it. So I suspect
you are not using the correct version of libpfm. Make sure you have
the latest library
installed (libpfm-3.3).

>  max counters/set: 2
>  supported PMU models: [AMD64] [Pentium 4] [Intel Core] [Intel P6
>  processor] [Intel Pentium II] [Intel Pentium Pro] [Intel Pentium M]
(Continue reading)

stephane eranian | 1 Apr 2008 11:11

Re: perfmon2 code restructuring news

Hello Arnd,

On Tue, Apr 1, 2008 at 2:28 AM, Arnd Bergmann <arnd <at> arndb.de> wrote:
> stephane eranian wrote:
>  >  I have spent most of last week restructuring the current perfmon2
>  >  kernel code base to make it easier to isolate
>  >  features. That should make it easier for the merge with mainline given
>  >  that LKML people would like to receive
>  >  small patches each adding one feature at a time.
>
>  Ah, this looks really good. I haven't really followed the perfmon2
>  progress over the last few releases. What is your plan for submission
>  to upstream inclusion? I guess if you want to have a chance of getting

According to what I have heard from Morton. I need to submit very small
patches each adding one feature. The restructuring I am currently doing
aim at making this easier and will hopefully avoid having to maintain two
seperate code bases. I would like to isolate things a bit more so we would
be able to submit a patch that adds, let's per-thread counting, then system-wide
counting, then per-thread sampling and so on. That is not going to be
necessarily
easy.

>  it into 2.6.26, now would be the time to post the patches.
>  I can certainly offer some help getting it into shape for inclusion
>  if you're interested.
>
I don't think the code is yet ready to start submitting patches. We need
some more work to isolate things more. As I said the area of fous right
now should be the generic to arch-specific interface. There is also another
(Continue reading)

Arnd Bergmann | 1 Apr 2008 11:30
X-Face
Picon
Gravatar

Re: perfmon2 code restructuring news

On Tuesday 01 April 2008, stephane eranian wrote:
> On Tue, Apr 1, 2008 at 2:28 AM, Arnd Bergmann <arnd <at> arndb.de> wrote:
> > stephane eranian wrote:
> >  Ah, this looks really good. I haven't really followed the perfmon2
> >  progress over the last few releases. What is your plan for submission
> >  to upstream inclusion? I guess if you want to have a chance of getting
> 
> According to what I have heard from Morton. I need to submit very small
> patches each adding one feature. The restructuring I am currently doing
> aim at making this easier and will hopefully avoid having to maintain two
> seperate code bases. I would like to isolate things a bit more so we would
> be able to submit a patch that adds, let's per-thread counting, then system-wide
> counting, then per-thread sampling and so on. That is not going to be
> necessarily easy.

Note that splitting the patches for review doesn't mean that you have
to split the implementation into smaller files, although often these
go hand in hand.

Also, not every patch has to be meaningful by itself, the strict requirement
is just that adding one aspect of the code doesn't break anything.
E.g. one patch can add a file that can't be used by itself, as long as
it doesn't get enabled in the Makefile.
If it's possible to add functionality in separate units, that's much
better than just adding all files as separate patches and then adding
the Makefile, but OTOH the main purpose of the splitting is to make
reviewing the different aspects easier.

> >  it into 2.6.26, now would be the time to post the patches.
> >  I can certainly offer some help getting it into shape for inclusion
(Continue reading)


Gmane