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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
