Carl Love

On Thu, 2019-07-25 at 14:39 +0000, William Cohen wrote: status: open --> open-fixed Group: --> Comment: I massaged the patch as it wasn't formatted quite right and didn't apply with a "git am". The logic seems reasonable and I verified that the patch fixed the stated problem. It is now in the upstrem oprofile git repository. Thanks. Will: Thanks. It was generated via git gui so not sure why it wouldn't apply with git am. Carl Love

Patch was committed by Will Cohen. The commit entry is: commit 8aacb573cd2c4a2f8160d99ff100ad0aa5e7859d Author: Carl Love cel@us.ibm.com Date: Thu Jul 25 10:24:16 2019 -0400 Only start the application if the perf events setup was successful Changes the order of starting the application and performance events. Given this change we have a new issue. The issue is the routine start_counting() calls fork, creating app_PID process. The parent then tries to setup the performance events, then if the performance...

The second patch can be used to force the error seen by the user. It is for testing purposes only and is not be committted to the repository. Will, let me know if you can read the patches OK or not. Thanks.

Per Will's request, I am attaching the two patches separately. The first patch is the fix for the issue.

I have attached the message/patch sent to the mailing list.

ocount leaves orphan process on error

The first issue noted was perf failed to start with "ocount --system-wide -e PM_L1MISS_LAT_EXC_32". Tested on a Power 8 system: /pe_counting# ocount --system-wide -e PM_L1MISS_LAT_EXC_32 ocount: Press Ctl-c or 'kill -SIGINT 122560' to stop counting ^C Events were actively counted for 3.3 seconds. Event counts (actual) for the whole system: Event Count % time counted PM_L1MISS_LAT_EXC_32 101,107 100.00 That does give non zero results, no perf errors. I tried the 256, 1024 and 2048 events as well and...

I believe this issue can be closed.