On Tue, 14 Aug 2018 at 11:09, Kim Phillips [off-list ref] wrote:

On Tue, 14 Aug 2018 10:15:56 -0600
Mathieu Poirier [off-list ref] wrote:

quoted

On Mon, 13 Aug 2018 at 11:46, Kim Phillips [off-list ref] wrote:

quoted

It yields success for the --per-thread case..:

$ sudo taskset -c 0 ./perf record -e cs_etm/@20010000.etf/ --per-thread uname -a
Linux juno 4.18.0-rc8-00011-gb82af52c4b35-dirty #147 SMP PREEMPT Thu Aug 9 11:20:37 CDT 2018 aarch64 GNU/Linux
[ perf record: Woken up 0 times to write data ]
Warning:
AUX data lost 1 times out of 2!

[ perf record: Captured and wrote 0.067 MB perf.data ]
$

..but not for CPU-wide?:

$ sudo taskset -c 0 ./perf record -e cs_etm/@20010000.etf/ uname -a
failed to mmap with 12 (Cannot allocate memory)
$ sudo taskset -c 0 ./perf record -e cs_etm/@20010000.etf/ -C 0 uname -a
failed to mmap with 12 (Cannot allocate memory)
$

This patchset is getting very old and a fair amount of things have
changed since then.  I'm hoping to be coming out with a new one
shortly.  Nonetheless the above is returning an error in CPU-wide
scenarios while the feature is being implemented.  Isn't what you
requested or have I misunderstood your comment?

No, sigh, I just automatically assumed the patchset would include
CPU-wide support again.  If it were being done that way, we'd all know
that the feature(s) this patchset adds would be doing the right thing
for that purpose, guaranteed.

The patchset published on this list never had support for CPU-wide scenarios.

This is only a preparatory step, the first one in a few more to come.
Sending the whole thing in one go would be way too heavy and is not
realistic.

The other thing that's going on here is that I'm becoming numb to the
loathsome "failed to mmap with 12 (Cannot allocate memory)" being
returned no matter what the error is/was. E.g., an error that would
indicate a sense of non-implementation would be much better
appreciated than presumably what the above is doing, i.e., returning
-ENOMEM.  That, backed up with specific details in the form of human
readable text in dmesg would be *most* welcome.

As part of the refactoring of the code to support CPU-wide scenarios I
intend to emit better diagnostic messages from the driver.  Modifying
rb_alloc_aux() to propagate the error message generated by the
architecture specific PMUs doesn't look hard either and I _may_ get to
it as part of this work.

Mathieu

Thanks,

Kim