From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751755AbbBVISs (ORCPT ); Sun, 22 Feb 2015 03:18:48 -0500 Received: from mail-wi0-f174.google.com ([209.85.212.174]:39277 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243AbbBVISq (ORCPT ); Sun, 22 Feb 2015 03:18:46 -0500 Date: Sun, 22 Feb 2015 09:18:40 +0100 From: Ingo Molnar To: Borislav Petkov Cc: Andy Lutomirski , Oleg Nesterov , Rik van Riel , x86@kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Arjan van de Ven Subject: Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs Message-ID: <20150222081840.GA22972@gmail.com> References: <20150221093150.GA27841@gmail.com> <20150221163840.GA32073@pd.tnic> <20150221172914.GB32073@pd.tnic> <20150221183952.GD8406@gmail.com> <20150221191527.GC32073@pd.tnic> <20150221192352.GA10027@gmail.com> <20150221213625.GD32073@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150221213625.GD32073@pd.tnic> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Borislav Petkov 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