All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.