linux-kernel - Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs

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: <20150222081840.GA22972@gmail.com>
Date:	Sun, 22 Feb 2015 09:18:40 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Oleg Nesterov <oleg@...hat.com>,
	Rik van Riel <riel@...hat.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs


* Borislav Petkov <bp@...en8.de> wrote:

> which spit this:
> 
> Lazy FPU:
>      219.127929718 seconds time elapsed

> Eager FPU:
>      220.148034331 seconds time elapsed

> so we have a second slowdown and 200K FPU saves more in eager mode.

So am I interpreting the older and your latest numbers 
correctly in stating that the cost observation has flipped 
around 180 degrees: the first measurement showed eager FPU 
to be a win, but now that we can do more precise 
measurements, eager FPU has actually slowed down the kernel 
build by ~0.5%?

That's not good, and kernel builds are just a random load 
that isn't even that FPU or context switch heavy - there 
will certainly be other loads that would be hurt even more.

So just before we base wide reaching decisions based on any 
of these measurements, would you mind help us increase our 
confidence in the numbers some more:

  - It might make sense to do a 'perf stat --null --repeat'
    measurement as well [without any -e arguments], to make 
    sure the rich PMU stats you are gathering are not 
    interfering?

    With 'perf stat --null --repeat' perf acts essenially 
    as a /usr/bin/time replacement, but can measure down to
    microseconds and will calculate noise/sttdev properly.

  - Perhaps also double check the debug switch: is it
    really properly switching FPU handling mode?

  - Do you have enough RAM that there's essentially no IO
    in the system worth speaking of? Do you have enough RAM
    to copy a whole kernel tree to /tmp/linux/ and do the
    measurement there, on ramfs?

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/