linux-kernel - Re: [RFC PATCH 00/50] tools/perf: Speed up the build system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Oct 2013 11:02:34 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...hat.com>
Subject: Re: [RFC PATCH 00/50] tools/perf: Speed up the build system

* Andi Kleen <andi@...stfloor.org> wrote:

> Ingo Molnar <mingo@...nel.org> writes:
> >
> > The series also includes a number of fixes and convenience features:
> >
> >    - auto-detect the number of CPUs on the system and add the -j<cpus>
> >      option automatically
> 
> FWIW I would prefer if you not do that automatically, because:
>
> - Often the optimal factor is not 1, but something like 1.5*CPUs (but 
> I'm not sure it's the same on all systems, probably depends on the IO 
> capacity and memory)

In my experience on numerous systems perf builds are rarely IO bound. But 
it could be upped to a factor of 1.5x without hurting the normal case if 
someone does convincing measurements.

> - It may use a lot of memory, so should be something controlled by the 
> user.

Lamest excuse evar: if your box cannot take NR_CPUs make jobs then you can 
tune it down. (You'll run into many other problems first though, before 
you start worrying about the perf build memory use.)

In the unlikely case of building it on a limited but SMP capable system 
with less than ~100 MB of free RAM you can override it:

  $ make
      BUILD: Doing 'make -j12' parallel build

  $ make JOBS=1
      BUILD: Doing 'make -j1' parallel build

Problem solved.

> - Often it's useful to use a few threads less to avoid interactivity 
> problems on a workstation.

Many people use 2*NR_CPUS for kernel builds and report interactivity 
problems relentlessly.

> - With LTO there can be rare cases where you need to lower it to avoid 
> running out of memory.

Oh, so out you come with the real reason, near the end of your list of 
complaints. Not a very honest approach.

If LTO is implemented correctly for a project then the biggest memory 
usage peak is during the final linking stage - which is single threaded...

> - Kernel build users should be already trained to set that parameter and 
> it's not really a big burden.

Second lamest excuse evar.

Really, 'make' doing the right thing out of box is a basic usability 
feature.

All other concerns you listed are secondary: they occur for specialized 
users or usecases, which need special care and hand-tuning anyway.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/