From: Ingo Molnar <mingo@elte.hu>
To: Ken Chen <kenchen@google.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [patch] x86: convert rdtscll() to use __native_read_tsc
Date: Tue, 16 Dec 2008 10:15:09 +0100 [thread overview]
Message-ID: <20081216091509.GA29872@elte.hu> (raw)
In-Reply-To: <b040c32a0812160032pf681f13s9e5e86c4b5448012@mail.gmail.com>
* Ken Chen <kenchen@google.com> wrote:
> Is there any reason why x86 rdtscll have to use the out of line function
> instead of inline __native_read_tsc()? native_read_tsc and
> __native_read_tsc is essentially the same functions.
Your patch is correct.
The reason for the __native_read_tsc() / native_read_tsc() distinction is
and obscure problem with paravirt function pointers. Such constructs:
./xen/enlighten.c: .read_tsc = native_read_tsc,
do not always work fine with all versions of gcc, if native_read_tsc() is
a simple static inline (as it should be) - the build would fail with
certain gcc flags. (and i remember runtime problems too) The C semantics
of taking the address of an inline function seem pretty clear: the inlined
function should be instantiated in that .o and a pointer should be
generated out of that local instantiation.
Perhaps the real fix is to do this rename as well:
native_read_tsc => native_read_tsc_paravirt
__native_read_tsc => native_read_tsc
as this makes the native_read_tsc_paravirt() a pure technical variant, to
be used in paravirt_ops function pointer assignments. People would thus
just use the obvious native_read_tsc() inline function most of the time
and could forget about native_read_tsc_paravirt().
Jeremy?
Ingo
next prev parent reply other threads:[~2008-12-16 9:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-16 8:32 [patch] x86: convert rdtscll() to use __native_read_tsc Ken Chen
2008-12-16 9:15 ` Ingo Molnar [this message]
2008-12-16 9:26 ` Jeremy Fitzhardinge
2008-12-16 10:15 ` Ingo Molnar
2008-12-17 8:07 ` Ken Chen
2008-12-18 13:31 ` Ingo Molnar
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=20081216091509.GA29872@elte.hu \
--to=mingo@elte.hu \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=kenchen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.