From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>,
Oleg Nesterov <oleg@redhat.com>, Rik van Riel <riel@redhat.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs
Date: Sun, 22 Feb 2015 09:18:40 +0100 [thread overview]
Message-ID: <20150222081840.GA22972@gmail.com> (raw)
In-Reply-To: <20150221213625.GD32073@pd.tnic>
* Borislav Petkov <bp@alien8.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
next prev parent reply other threads:[~2015-02-22 8:18 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 18:58 [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs Andy Lutomirski
2015-02-20 19:05 ` Borislav Petkov
2015-02-21 9:31 ` Ingo Molnar
2015-02-21 16:38 ` Borislav Petkov
2015-02-21 17:29 ` Borislav Petkov
2015-02-21 18:39 ` Ingo Molnar
2015-02-21 19:15 ` Borislav Petkov
2015-02-21 19:23 ` Ingo Molnar
2015-02-21 21:36 ` Borislav Petkov
2015-02-22 8:18 ` Ingo Molnar [this message]
2015-02-22 8:22 ` Ingo Molnar
2015-02-22 10:48 ` Borislav Petkov
2015-02-22 12:50 ` Borislav Petkov
2015-02-22 12:57 ` Ingo Molnar
2015-02-22 13:21 ` Borislav Petkov
2015-02-22 0:34 ` Maciej W. Rozycki
2015-02-22 2:18 ` Andy Lutomirski
2015-02-22 11:06 ` Borislav Petkov
2015-02-23 1:45 ` Rik van Riel
2015-02-23 5:22 ` Andy Lutomirski
2015-02-23 12:51 ` Rik van Riel
2015-02-23 15:03 ` Borislav Petkov
2015-02-23 15:51 ` Rik van Riel
2015-02-23 18:06 ` Borislav Petkov
2015-02-23 21:17 ` Maciej W. Rozycki
2015-02-23 21:21 ` Rik van Riel
2015-02-23 22:14 ` Linus Torvalds
2015-02-24 0:56 ` Maciej W. Rozycki
2015-02-24 0:59 ` Andy Lutomirski
2015-02-23 22:27 ` Maciej W. Rozycki
2015-02-23 23:44 ` Andy Lutomirski
2015-02-24 2:14 ` Maciej W. Rozycki
2015-02-24 2:31 ` Andy Lutomirski
2015-02-24 14:43 ` Rik van Riel
2015-02-21 18:34 ` Ingo Molnar
2015-02-23 14:59 ` Oleg Nesterov
2015-02-23 15:11 ` Borislav Petkov
2015-02-23 15:53 ` Rik van Riel
2015-02-23 18:40 ` Oleg Nesterov
2015-02-24 19:15 ` Denys Vlasenko
2015-02-25 0:07 ` Andy Lutomirski
2015-02-25 10:37 ` Borislav Petkov
2015-02-25 10:50 ` Ingo Molnar
2015-02-25 10:45 ` Ingo Molnar
2015-02-25 17:12 ` Some results (was: Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs) Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150222081840.GA22972@gmail.com \
--to=mingo@kernel.org \
--cc=arjan@infradead.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=oleg@redhat.com \
--cc=riel@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox