[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1246717039.2329.26.camel@jaswinder.satnam>
Date: Sat, 04 Jul 2009 19:47:19 +0530
From: Jaswinder Singh Rajput <jaswinder@...nel.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Arjan van de Ven <arjan@...radead.org>,
Frédéric Weisbecker <fweisbec@...il.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Paul Mackerras <paulus@...ba.org>,
Anton Blanchard <anton@...ba.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
x86 maintainers <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 4/6 -tip] perf_counter: Add Generalized Hardware
interrupt support for AMD
On Sat, 2009-07-04 at 12:22 +0200, Ingo Molnar wrote:
> * Jaswinder Singh Rajput <jaswinder@...nel.org> wrote:
>
> > On Wed, 2009-07-01 at 13:24 +0200, Ingo Molnar wrote:
> > > * Jaswinder Singh Rajput <jaswinder@...nel.org> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists