On Mon, Sep 26, 2011 at 8:27 AM, David Long <dave.l...@linaro.org> wrote: > Andy made an interesting suggestion to me. What if the profile event code > allocated all the counters to the requested event. It could reallocate half > of them if a second event was also requested, and so on, till we're down to > one (unreliably interrupting) counter. Or we could set a limit requiring at > least three counters per event. > > The problem would still exist, but this should throw the maximum amount of > ammunition we have towards minimizing it. Would this be worth the effort to > implement?
Please just do something :) I don't see why you can't supply the kernels with oprofile working in timer mode with a usable sampling frequency *right now*. That should be enough for the helpless users who can't or don't want to tweak and build their own kernels. And some kind of workaround for A8/A9 PMU can be always applied later once/if you get it working reliable enough. Also I don't know any details about A9 PMU problems, but the chance of encountering the missed PMU interrupt bug on A8 really depends on the use case which you are profiling. The code which uses lots of syscalls and spends a lot of time in the parts of the kernel accessing the problematic CP14/CP15 registers naturally has a *much* higher chance of triggering the bug. So if somebody says that the failure rate is very close to 0% and can be ignored, this may be not always the case. The whole situation reminds me of one part of some stupid Seagal movie: * 'mad scientist' villain : babbling something about how complex his system is and how it can't be stopped * the hero : shoots at the laptop * 'mad scientist' villain : I didn't think of that Come on, making oprofile practically usable on all ARM boards and devices is not that difficult. -- Best regards, Siarhei Siamashka _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
