linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: john stultz <johnstul@us.ibm.com>
Cc: Joel Becker <Joel.Becker@oracle.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Subject: Re: get_cycles() on i386
Date: Tue, 4 Nov 2003 15:54:36 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0311041545030.20373-100000@home.osdl.org> (raw)
In-Reply-To: <1067988463.11437.115.camel@cog.beaverton.ibm.com>


On 4 Nov 2003, john stultz wrote:
> 
> CONFIG_X86_TSC be the devil. Personally, I'd much prefer dropping the
> compile time option and using dynamic detection. Something like (not
> recently tested and i believe against 2.5.something, but you get the
> idea):

Some of the users are really timing-critical (eg scheduler).

How about just using the "alternative()" infrastructure that we already 
have in 2.6.x for this? See <asm-i386/system.h> for details.

We don't have an "alternative_output()" available yet, but using that it
would look something like:

	static inline unsigned long long get_cycle(void)
	{
		unsigned long long tsc;

		alternative_output(
			"xorl %%eax,%%eax ; xorl %%edx,%%edx",
			"rdtsc",
			X86_FEATURE_TSC,
			"=A" (tsc));
		return tsc;
	 }

which should allow for "perfect" code (well, gcc tends to mess up 64-bit 
stuff, but you get the idea).

We use the "alternative_input()" thing for prefetch() handling (see 
<asm-i386/processor.h>).

		Linus


  reply	other threads:[~2003-11-04 23:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-04 23:22 Joel Becker
2003-11-04 23:27 ` john stultz
2003-11-04 23:54   ` Linus Torvalds [this message]
2003-11-05  2:53     ` Nick Piggin
2003-11-05  3:02       ` Nick Piggin
2003-11-05 13:35     ` Marcelo Tosatti
2003-12-05 15:55   ` Marcelo Tosatti

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=Pine.LNX.4.44.0311041545030.20373-100000@home.osdl.org \
    --to=torvalds@osdl.org \
    --cc=Joel.Becker@oracle.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.tosatti@cyclades.com \
    --subject='Re: get_cycles() on i386' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).