From: Jean Pihet <jpihet@mvista.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Siarhei Siamashka <siarhei.siamashka@nokia.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.arm.linux.org.uk"
<linux-arm-kernel@lists.arm.linux.org.uk>,
"oprofile-list@lists.sourceforge.net"
<oprofile-list@lists.sourceforge.net>
Subject: Re: get_irq_regs() from soft IRQ
Date: Mon, 29 Jun 2009 19:52:20 +0200 [thread overview]
Message-ID: <200906291952.20624.jpihet@mvista.com> (raw)
In-Reply-To: <20090629173757.GC9042@n2100.arm.linux.org.uk>
On Monday 29 June 2009 19:37:57 Russell King - ARM Linux wrote:
> On Mon, Jun 29, 2009 at 07:36:57PM +0300, Siarhei Siamashka wrote:
> > On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
> > > I am trying to get the latest IRQ registers from a timer or a work
> > > queue but I am running into problems:
> > > - get_irq_regs() returns NULL in some cases, so it is unsuable and even
> > > causes crash when trying to get the registers values from the returned
> > > ptr - I never get user space registers, only kernel
> > >
> > > The use case is that the performance unit (PMNC) of the Cortex A8 has
> > > some serious bug, in short the performance counters overflow IRQ is to
> > > be avoided. The solution I am implementing is to read and reset the
> > > counters from a work queue that is triggered by a timer.
> >
> > Regarding this oprofile related part. I wonder how you can get oprofile
> > working properly (providing non-bogus results) without performance
> > counters overflow IRQ generation?
>
> I don't think you can - triggering capture on overflow is precisely how
> oprofile works.
>
> The erratum talks about polling for overflow. By doing this, you are in
> a well defined part of the kernel, which is obviously going to be shown
> as a hot path for every counter, thus making oprofile useless for kernel
> work.
I think it is possible, well if you except the get_irq_regs() problem.
The idea is to read and reset the counters before the overflow, instead of
loading them with a small negative value and waiting for the overflow to
happen.
> Deferring the interrupt to a workqueue doesn't resolve the problem either.
> The problem has nothing to do with what happens after the interrupt
> occurs - it's about interrupts themselves being lost.
The errata is about a lost event and/or a lock-up of the PMNC unit at the time
of overflow.
> I think just accepting that this erratum breaks oprofile is the only
> realistic solution. ;(
Completely agree. However it would be nice to have a workaround, as un-elegant
as it can be ;(
next prev parent reply other threads:[~2009-06-29 17:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-29 14:31 get_irq_regs() from soft IRQ Jean Pihet
2009-06-29 15:19 ` Russell King - ARM Linux
2009-06-29 15:35 ` Jean Pihet
2009-06-29 16:07 ` Russell King - ARM Linux
2009-06-29 16:12 ` Jean Pihet
2009-06-29 16:36 ` Siarhei Siamashka
2009-06-29 16:58 ` Jean Pihet
2009-06-29 17:46 ` Russell King - ARM Linux
2009-06-29 17:57 ` Jean Pihet
2009-06-29 17:54 ` Siarhei Siamashka
2009-06-29 18:08 ` Jean Pihet
2009-06-29 17:37 ` Russell King - ARM Linux
2009-06-29 17:52 ` Jean Pihet [this message]
2009-06-29 18:38 ` Siarhei Siamashka
2009-06-29 18:49 ` Jean Pihet
2009-06-29 19:45 ` Siarhei Siamashka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200906291952.20624.jpihet@mvista.com \
--to=jpihet@mvista.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=oprofile-list@lists.sourceforge.net \
--cc=siarhei.siamashka@nokia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox