linux-kernel - Re: [GIT PULL] perf fixes

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20130912201855.GC32644@gmail.com>
Date:	Thu, 12 Sep 2013 22:18:55 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	David Ahern <dsahern@...il.com>
Cc:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] perf fixes

* David Ahern <dsahern@...il.com> wrote:

> On 9/12/13 11:43 AM, Arnaldo Carvalho de Melo wrote:

> > Its something that annoys me as well, but not so much as to make me 
> > figure out how to make those be done only if some source file changed.
> 
> Jiri and I have both taken stabs at a config-based build rather than 
> probing. Just need to finish it.

Mind outlining the approach you are thinking about?

Firstly, please don't even think about autotools. (Just forget it exists.)

Secondly, the way perf tries to build by auto-detecting the build 
environment and auto-disabling bits it cannot build just yet is pretty 
powerful. The core bits will build on just about any system, and our 
fallbacks are really good.

The result is that perf will build on just about any random system, 
without the user having to install any dependency. It would be really sad 
to lose that aspect.

What I think would work best is what I outlined in the previous mail: to 
cache successful feature test results and only re-do unsuccessful tests: 
those are the ones that are expected to turn into successful tests in the 
future, once the missing dependencies are installed.

Since most tests succeed even on a sparsely installed system, this trick 
alone will speed up the checks big time.

Furthermore, this method would encourage people to install the 
dependencies - and perf developers, who do many repeat builds after 
trivial one-file changes, will typically have all dependencies installed 
anyway, so for them such a caching feature would result in totally cached 
feature tests and very fast build times.

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/