From: Andi Kleen <andi@firstfloor.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Bernd Schubert <bs@q-leap.de>,
linux-kernel@vger.kernel.org, Andi Kleen <andi@firstfloor.org>
Subject: Re: frame unwinder patches
Date: Fri, 5 Sep 2008 17:08:33 +0200 [thread overview]
Message-ID: <20080905150833.GU18288@one.firstfloor.org> (raw)
In-Reply-To: <20080905075703.6041650e@infradead.org>
> to be honest, on 64 bit the overhead is quite small (the extra
> instructions it adds are optimized for by the modern cpus that you use
The pipeline dependency stalls yes, the icache/decode overhead no.
Also CONFIG_FRAME_POINTER currently enables -fno-sibling-calls
which generates significantly worse code for a lot of common
kernel constructs.
> in the systems you're selling); on 32 bit the overhead is.. well a
> little bigger but not THAT much. yes it loses a register for the
> compiler to use, but no it's not a general purpose register, and with
%rbp is a general purpose register. In fact it's even better
than a general purpose register because it has often shorter
encoding than the other registers, but is as versatile.
> the register renaming that today's cpus do, I'd be surprised if you
> could see anything significant.
Even on modern CPUs you can measure it in macro benchmarks, at
least that was the state last time that was investigated.
On older CPUs without the magic hardware it was even more
significant. Also there are even new CPUs like Atom which don't
have the magic hardware.
-Andi
next prev parent reply other threads:[~2008-09-05 15:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-04 16:46 frame unwinder patches Bernd Schubert
2008-09-04 17:29 ` Arjan van de Ven
2008-09-05 9:19 ` Bernd Schubert
2008-09-05 13:33 ` Arjan van de Ven
2008-09-05 13:52 ` Bernd Schubert
2008-09-05 14:13 ` Arjan van de Ven
2008-09-05 14:48 ` Bernd Schubert
2008-09-05 14:57 ` Arjan van de Ven
2008-09-05 15:08 ` Andi Kleen [this message]
2008-09-04 19:13 ` Andi Kleen
2008-09-05 9:24 ` Bernd Schubert
2008-09-05 9:43 ` Andi Kleen
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=20080905150833.GU18288@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=bs@q-leap.de \
--cc=linux-kernel@vger.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