public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Thomas J. Merritt" <tjm@codegen.com>
To: Peter Tattam <peter@jazz-1.trumpet.com.au>
Cc: linux-kernel@vger.kernel.org, discuss@x86-64.org
Subject: Re: [discuss] Re: [Bug 350] New: i386 context switch very slow compared to 2.4 due to wrmsr (performance)
Date: Thu, 13 Feb 2003 20:07:07 -0800	[thread overview]
Message-ID: <200302140407.h1E477oP041875@tenor.codegen.com> (raw)
In-Reply-To: Your message of Fri, 14 Feb 2003 13:01:30 +1100. <Pine.BSF.3.96.1030214125805.16984A-100000@jazz-1.trumpet.com.au>

|<><><><><> Original message from Peter Tattam  <><><><><>
|On Thu, 13 Feb 2003, Eric Northup wrote:
|
|> On Thursday 13 February 2003 07:14 pm, Peter Tattam wrote:
|> > On Thu, 13 Feb 2003, Andi Kleen wrote:
|> > > [Hmm, this is becomming a FAQ]
|> > >
|> > > > Switching in and out of long mode is evil enough that I don't think it
|> > > > is worth it.  And encouraging people to write good JIT compiling
|> > >
|> > > Forget it. It is completely undefined in the architecture what happens
|> > > then. You'll lose interrupts and everything. Nothing for an operating
|> > > system intended to be stable.
|> > >
|> > > I have no plans at all to even think about it for Linux/x86-64.
|> [snip]
|> >
|> > The only other unknown quantity is the time it takes for the CPU to
|> > enable/disable long mode, but with modern CPU speeds, the interrupt latency
|> > may only be mildy affect by such a process, unless the CPU is broken in
|> > some way. I see no discussion in the AMD manuals regarding the cost of the
|> > mode switch, only what AMD engineers have hinted at.
|> 
|> I think the real issue is that AMD neither recommends nor supports this 
|> strategy.  ( http://www.x86-64.org/lists/discuss/msg02964.html ... there were
| 
|> better posts but I couldn't find them)  People with real hardware can't talk 
|> about it right now, but it seems to me this is just begging to get hit by 
|> errata -- how much effore do you think team Hammer spent testing a subtle 
|> mode transition which is marked "Don't do that!" ?
|> 
|
|well, I guess AMD need to come out & explicitly state this somewhere other than
|on a mailing list.   I wouldn't be only one tempted to see if it can be done,
|and if it becomes "necessary" for some OSes, AMD will get locked into a
|backward compatibility minefield.  Anyone know what Windows 64 does about this
|issue?  If Microsoft considers that it is sufficient to warp the CPU for v86
|emulation, it may just be a done deal.

The only way to get from long-mode back to legacy-mode is to reset the
processor.  It can be done in software but you will likely lose interrupts.
Attempting to switch out of long-mode by modifying EFER will just get you a #GP
fault.  You might want to read Volume 2 section 14.6.2.

TJ Merritt
tjm@codegen.com
1-925-462-4300 x115

  reply	other threads:[~2003-02-14  3:57 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-12  1:35 [Bug 350] New: i386 context switch very slow compared to 2.4 due to wrmsr (performance) Martin J. Bligh
2003-02-12  2:59 ` Dave Jones
2003-02-12  4:21   ` Jamie Lokier
2003-02-12  5:49     ` Linus Torvalds
2003-02-12 10:12       ` Jamie Lokier
2003-03-10  3:07         ` Linus Torvalds
2003-03-10 11:06           ` Andi Kleen
2003-03-10 18:33             ` Linus Torvalds
2003-03-10 22:44           ` Linus Torvalds
2003-02-12 12:54     ` Dave Jones
2003-02-12  7:50   ` Andi Kleen
2003-02-12 10:27     ` Jamie Lokier
2003-02-12 10:45       ` Andi Kleen
2003-02-12 17:52         ` Ingo Oeser
2003-02-12 18:13           ` Dave Jones
2003-02-12 18:18           ` Andi Kleen
2003-02-13  2:42             ` Alan Cox
2003-02-13  5:17         ` Eric W. Biederman
2003-02-13 18:07           ` Andi Kleen
2003-02-14  0:14             ` [discuss] " Peter Tattam
2003-02-14  1:29               ` Andi Kleen
2003-02-14  1:51               ` Eric Northup
2003-02-14  2:01                 ` Peter Tattam
2003-02-14  4:07                   ` Thomas J. Merritt [this message]
2003-02-14  9:38                     ` Peter Finderup Lund
2003-02-14  8:27               ` Eric W. Biederman
2003-03-19  1:22             ` Rob Landley
2003-02-12  4:18 ` Jamie Lokier
2003-02-12  5:54   ` Linus Torvalds
2003-02-12 10:18     ` Jamie Lokier
2003-02-12 17:24       ` Linus Torvalds
2003-03-18 15:24     ` Kevin Pedretti
2003-03-18 16:41       ` Linus Torvalds
2003-03-18 18:30         ` Brian Gerst
2003-03-18 19:14           ` Thomas Molina
2003-03-18 19:21           ` Linus Torvalds
2003-03-18 20:03             ` Thomas Schlichter
2003-03-18 20:24             ` Steven Cole
2003-03-19  0:42             ` H. Peter Anvin
2003-03-19  2:22               ` george anzinger
  -- strict thread matches above, loose matches on Subject: below --
2003-02-14 14:03 [discuss] " Robert Dewar
2003-02-14 14:25 ` Peter Finderup Lund
2003-02-14 14:25 ` Peter Finderup Lund

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=200302140407.h1E477oP041875@tenor.codegen.com \
    --to=tjm@codegen.com \
    --cc=discuss@x86-64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter@jazz-1.trumpet.com.au \
    /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