linux-kernel - Re: [PATCHv2] x86: add kconfig options for newer 64-bit processors

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:	Mon, 21 Oct 2013 15:59:18 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>
Cc:	Linux-Kernel mailing list <linux-kernel@...r.kernel.org>,
	x86@...nel.org, Linux Torvalds <torvalds@...l.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCHv2] x86: add kconfig options for newer 64-bit processors

On Mon, Oct 21, 2013 at 07:44:53AM -0400, Austin S Hemmelgarn wrote:
> Specifically, boot time was reduced by approximately half a second
> (measured as time from starting init till having a usable graphical
> login),

How did you measure that? Kernel printk timestamps? I keep repeating
this and you simply don't state your benchmarking methods clearly
enough, for some reason: I need a detailed explanation about how exactly
you're doing your measurements so that I or anyone else for that matter,
can repeat them.

> and the system ran approximately 1 degree cooler under heavy
> load (namely a full GCC+binutils bootstrap with one job per virtual
> CPU core).

Ditto.

> Using lm_sensors with CONFIG_FAM15H_POWER enabled, simply run the
> command `sensors` a couple of times on an idle system as root comparing
> the values between having CONFIG_MPILEDRIVER=y and CONFIG_GENERIC_CPU=y.
> For this specific case I recorded the wattage values at one minute

That's too coarse-grained since the sensors output will give your
momentary power consumption. But I see what you do here and I'll run a
modified, more finer-granulary test of yours on my machine too to check.

> Something else to keep in mind, the effects of -mtune=generic change
> over time, as these processors become less common, the optimizations

Which processors?

> done by -mtune=generic will shift away from them. The reason that many
> of the equivalent options in the kernel currently provide as much
> benefit as they do is that gcc no longer tries to create machine code
> that is tuned for them unless you tell it to.

This doesn't really make much sense because the single biggest build
target is distros with a single system image which is supposed to run as
optimally as possible on any x86 hardware.

So specialized builds are only for Gentoo users and others who build
customized kernels. And those who can do that, can also apply this patch
to their own tree.
--
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/