[lkml]   [2015]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: arm/arm64 perf build issue with mainline

* David Ahern <> wrote:

> On 4/23/15 5:29 AM, Will Deacon wrote:
> >Hi all,
> >
> >Commit 6428c59a97de ("perf tools: Set JOBS based on CPU or processor")
> >causes weird behaviour on arm/arm64 platforms because we use the "CPU"
> >prefix for things like:
> >
> >CPU implementer : 0x41
> >CPU architecture: 8
> >CPU variant : 0x0
> >CPU part : 0xd03
> >CPU revision : 0
> >
> >in /proc/cpuinfo. Consequently, a 6 core machine ends up doing:
> >
> >will@confinement-loaf:~/linux/tools/perf$ make
> > BUILD: Doing 'make -j36' parallel build
> >
> >which is a little overwhelming. Any chance we can predicate the extra
> >part of the regex on $(ARCH) being sparc?

That regex needs to be fixed or replaced with a more robust 'number of
CPUs on the system' discovery method.

> Frankly, I think the JOBS parameter needs to be removed. It's
> non-standard way of controlling parallelism in the build and it
> makes the assumption that if a system has N processors all of those
> can be used to build perf which is not true if you are building perf
> as part of bigger image builds -- like Yocto for example.
> Ingo: As I recall you put this in? Opinions on removing it?

I disagree strongly!

> [...] Users can always add the standard '-j N' for parallelism just
> like they do for kernel builds.

So for a few oddball cases we remove something that improves usability
quite visibly? 'make' or 'make install' will do the right thing today
on 99.9% of the systems, and it should do that in the future as well.

We should not add extra usability barriers that hurts the regular

This usability concept permeates all of perf: that's why 'perf top'
will measure all CPUs by default, although there are certainly cases
where that's not what the user wants.



 \ /
  Last update: 2015-05-11 10:41    [W:0.144 / U:8.676 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site