From: "J.E.J. Bottomley" <James.Bottomley@steeleye.com>
To: john stultz <johnstul@us.ibm.com>
Cc: "J.E.J. Bottomley" <James.Bottomley@SteelEye.com>,
Vojtech Pavlik <vojtech@suse.cz>,
Linus Torvalds <torvalds@transmeta.com>,
Pavel Machek <pavel@ucw.cz>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
"J.E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Voyager subarchitecture for 2.5.46
Date: Mon, 11 Nov 2002 17:49:56 -0500 [thread overview]
Message-ID: <200211112249.gABMnux21337@localhost.localdomain> (raw)
In-Reply-To: Message from john stultz <johnstul@us.ibm.com> of "11 Nov 2002 13:58:44 PST." <1037051926.3844.4.camel@cornchips>
johnstul@us.ibm.com said:
> We'd still need to go back and yank out the #ifdef CONFIG_X86_TSC'ed
> macros in profile.h and pksched.h or replace them w/ inlines that wrap
> the rdtsc calls w/ if(cpu_has_tsc && !tsc_disable) or some such line.
Actually, the best way to do this might be to vector the rdtsc calls through a
function pointer (i.e. they return zero always if the TSC is disabled, or the
TSC value if it's OK). I think this might be better than checking the
cpu_has_tsc flag in the code (well it's more expandable anyway, it won't be
faster...)
When the TSC code is sorted out on a per cpu basis, consumers are probably
going to expect rdtsc to return usable values whatever CPU it is called on, so
vectoring the calls now may help this.
James
next prev parent reply other threads:[~2002-11-11 22:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-05 20:45 Voyager subarchitecture for 2.5.46 J.E.J. Bottomley
2002-11-06 2:31 ` john stultz
2002-11-06 13:43 ` Alan Cox
2002-11-06 21:35 ` john stultz
2002-11-06 15:03 ` J.E.J. Bottomley
2002-11-06 15:38 ` Alan Cox
2002-11-06 16:09 ` Christer Weinigel
2002-11-06 15:45 ` Linus Torvalds
2002-11-06 16:19 ` Alan Cox
2002-11-06 16:12 ` Linus Torvalds
2002-11-06 16:45 ` Alan Cox
2002-11-10 16:30 ` Pavel Machek
2002-11-10 18:59 ` Linus Torvalds
2002-11-10 19:18 ` Pavel Machek
2002-11-10 19:31 ` Linus Torvalds
2002-11-10 19:42 ` Pavel Machek
2002-11-10 19:48 ` Vojtech Pavlik
2002-11-10 20:02 ` Sean Neakums
2002-11-10 20:16 ` Lars Marowsky-Bree
2002-11-10 22:11 ` Alan Cox
2002-11-10 19:46 ` Vojtech Pavlik
2002-11-11 20:40 ` john stultz
2002-11-11 20:57 ` J.E.J. Bottomley
2002-11-11 21:36 ` William Lee Irwin III
2002-11-11 21:58 ` john stultz
2002-11-11 22:49 ` J.E.J. Bottomley [this message]
2002-11-11 23:12 ` john stultz
2002-11-12 12:16 ` Pavel Machek
2002-11-11 22:08 ` Vojtech Pavlik
2002-11-06 20:07 ` john stultz
2002-11-06 22:36 ` H. Peter Anvin
2002-11-06 19:30 ` john stultz
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=200211112249.gABMnux21337@localhost.localdomain \
--to=james.bottomley@steeleye.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=torvalds@transmeta.com \
--cc=vojtech@suse.cz \
/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