On Mon, Jul 11, 2016 at 04:58:35PM +0100, Mark Rutland wrote:

On Mon, Jul 11, 2016 at 10:05:39AM -0500, Jeremy Linton wrote:

quoted

On 07/07/2016 11:21 AM, Mark Rutland wrote:

quoted

Have you tested trying to stat on a particular PMU? e.g.

$ perf stat -e armv8_cortex_a53/cpu_cycles/ ls

I found that the presence of a cpumask file would cause (at least some
versions) of perf-stat to hang, and was holding off adding a cpumask
until we had a solution to that.

I guess that is more proof that any tiny change can break things..
Another "fix" is to make the cpumap_print_to_pagebuf's first
parameter false which apparently keeps perf from understanding the
cpu mask and forces the user to use numactl, which is ugly because
numactrl doesn't understand the mask in that format either.

If we have a cpumask, it should be in keeping with the usual style.

quoted

I guess fixing perf is probably the best bet here...

Indeed.

The major issue is that it's not clear to me how to avoid breaking
existing binaries when adding the cpumask. I suspect that we have to
expose it under a different name. :/

Well, we need to understand exactly why the cpumask breaks those older
perf builds before we do that. Is it expecting some behaviour that we
don't honour, or does it break on other architectures providing a
cpumask too?

quoted

quoted

See [1,2] for more details on that.

That makes it sound specific to big/little. Did perf used to work on
those systems without a cpumask? I understand that it might not have
hung, but did it actually provide meaningful data?

I'm not against renaming the cpumask if that's our only option, but I'd
like to understand (and document) how we arrive at that, if we actually
do.

Will