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]
Message-ID: <20131021135917.GA6117@nazgul.tnic>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ