Re: get_irq_regs() from soft IRQ

[Jean Pihet <jpihet@mvista.com>]

On Monday 29 June 2009 19:46:33 Russell King - ARM Linux wrote:
> On Mon, Jun 29, 2009 at 06:58:41PM +0200, Jean Pihet wrote:
> > I am trying to get a different approach, starting from the errata
> > description.  The idea is to avoid the counters from overflowing,
> > which could cause a PMNC unit reset or lock-up (or both).
>
> But this can't work.
>
> Oprofile essentially works as follows:
>
>   You set the number (N) of events you wish to occur between each sample.
>   When N events have occured, you record the stacktrace and reset the
>   counter so it fires after another N events.
>
> Now, you could start the counters at zero every time, and then poll them
> via a timer.  When the counter value is larger than N, you could log a
> stacktrace and zero the counter.
>
> However, this suffers one very serious problem - if you're wanting to
> measure something at an interval which occurs faster than your timer,
> you're going to get misleading results.
The counters are 32-bit wide and the maximum counting frequency is 2 events 
per cycle (cf. errata). That means you get plenty of time before the counters 
overflow.

> You could set the timer to fire at a high rate, but then that's going
> to upset things like cache miss, cache hit, etc measurements.
Correct.
You need a tradeoff for the timer period.

> > Here are the implementation details:
> > - use a timer to read and reset the counters, then fire a work queue
> > - in the work queue the counters values are converted to oprofile samples
> > - the proper locking is used to avoid some races between the various
> > tasks
>
> This sounds over complicated. 
It is ;p

> I see no reason for a workqueue to be 
> involved anywhere near the oprofile sample code.
Got it.

> > I am nearly done with it but I am now running into problems with PM
> > (suspend/resume) and get_irq_regs().
>
> You really really really can't use get_irq_regs() outside of IRQ context.
> The stored registers just do not exist anymore - they've been overwritten
> by whatever exception or system call you're currently in.
>
> You can't create a copy of them - copies will be overwritten on the very
> next (nested) interrupt.  You don't know which interrupt is the first
> interrupt to occur.
Doh!

> I really think that the only option here is to just accept that oprofile
> is crucified by this errata.
Amen!

Thanks,
Jean