Re: [PATCH 4/6 -tip] perf_counter: Add Generalized Hardwareinterrupt support for AMD

[Jaswinder Singh Rajput]

On Sat, 2009-07-04 at 12:22 +0200, Ingo Molnar wrote:
> * Jaswinder Singh Rajput <jaswinder@xxxxxxxxxx> wrote:
> 
> > On Wed, 2009-07-01 at 13:24 +0200, Ingo Molnar wrote:
> > > * Jaswinder Singh Rajput <jaswinder@xxxxxxxxxx> wrote:
> > > 
> > > > 
> > > > $ ./perf stat -e interrupts -e masked -e int-pending-mask-cycles -- ls -lR /usr/include/ > /dev/null
> > > > 
> > > >  Performance counter stats for 'ls -lR /usr/include/':
> > > > 
> > > >             377  interrupts
> > > >        53429936  int-mask-cycles
> > > >            1119  int-pending-mask-cycles
> > > > 
> > > >     0.371457539  seconds time elapsed
> > > 
> > > Agreed, this is another useful generalization - and the 'cycles 
> > > pending' metrics are not retrievable via any software means.
> > > 
> > > We could and should probably add a software counter for hardirqs 
> > > as wel. That would allow the vector/irqnr information to be 
> > > passed in, and it would allow architectures without irq metrics 
> > > in the PMU to have this counter too.
> > > 
> > 
> > Please let me know that addition of software counter will be in 
> > this patch or we can do it incrementally after this patch.
> 
> It should be in this series. That way we can cross-check whether the 
> soft counts and the hard counts match up and find potential bugs 
> that way, etc.
> 

You want to cross check performance counter events ?

Why you choose interrupt events, why do not you raise this point when
cache events was added ?

I do not understand why you keep going on tangents.

If you want to cross-check then it should be in different patch and
there should be no requirement to have this on this series and no point
of blocking this patch on irrelevant argument.

Only thing I can do is to fix the patch, if you point any problem in
this.

Thanks,
--
JSR

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/