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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.