From: Eric Northup <lkml@digitaleric.net>
To: Peter Tattam <peter@jazz-1.trumpet.com.au>, Andi Kleen <ak@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
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:51:35 -0500 [thread overview]
Message-ID: <200302132051.35268.lkml@digitaleric.net> (raw)
In-Reply-To: <Pine.BSF.3.96.1030214103845.369E-100000@jazz-1.trumpet.com.au>
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!" ?
> > > emulators sounds much better, especially in the long run. But it can
> > > be written.
> >
> > For DOS even a slow emulator should be good enough. After all most
> > DOS Programs are written for slow machines. Bochs running on a K8
> > will be hopefully fast enough. If not an JIT can be written, perhaps
> > you can extend valgrind for it.
> >
> > Or if you really rely on a DOS program executing fast you can
> > always boot a 32bit kernel which of course still supports vm86
> > in legacy mode.
>
> While an emulator sounds like a good idea, it is baggage that needs to be
> included. JIT is probably overkill if the hardware can already do it.
I am actually working on a dynamic translator for x86, and am starting with
16-bit real-mode. It's a bit OT for linux-kernel, and it's not done yet so
I'll spare you the details, but the point is that the kernel doesn't need to
do anything special to help an emulator/dynamic translator, and that it
*shouldn't* let you run real-mode code on the hardware.
> I contend that if the thunking code is reasonably well defined and thought
> out, jumping in & out of long mode might not be as big a hassle as
> originally thought.
Even the best code is subject to the limitations of the hardware it is run on.
-Eric
next prev parent reply other threads:[~2003-02-14 1:41 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 [this message]
2003-02-14 2:01 ` Peter Tattam
2003-02-14 4:07 ` Thomas J. Merritt
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=200302132051.35268.lkml@digitaleric.net \
--to=lkml@digitaleric.net \
--cc=ak@suse.de \
--cc=discuss@x86-64.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mailing-lists@digitaleric.net \
--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