archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <>
To: lkml <>
Subject: Re: TSCs are a no-no on i386
Date: Thu, 31 Jul 2003 09:17:19 +0200	[thread overview]
Message-ID: <20030731071719.GA26249@alpha.home.local> (raw)
In-Reply-To: <>

On Thu, Jul 31, 2003 at 08:22:52AM +0200, Jan-Benedict Glaw wrote:
> > The 486 emlation patch for 386 is the way to still allow 386's to run 
> > Debian.
> Okay, I'll have a look at it. Where's the 2.6.x version?

It doesn't exist, but could certainly easily be ported from 2.4.

But I think that people want to use it the wrong way. I wrote it to allow older
machines to *occasionally* run code designed for the wrong architecture. Eg,
your machine dies, you unplug the disk and puts it in another one, a smaller
one, and cross your fingers for the system to work again. In this case, I
think it's easier to compile a kernel with the right options to allow emulation
than to reinstall the system with the proper packages.

Now it seems to me that people want to use it as an excuse not to respect
architectural constraints and processors instructions sets. Of course, it's
easy to compile everything for i686 and think "well, if the machine doesn't
support this or that, then the kernel will do...". But you quickly end up in
even more slowing down small machines.

The other problem lies with the lock :
When a 486 executes "LOCK ; CMPXCHG", it locks the bus during the whole cmpxchg
instruction. If a 386 executes the same code, it will get an exception which
will be caught by the emulator. I don't see how we can do such an atomic
operation while holding a lock. At best, we would think about a global memory
based shared lock during the operation (eg: int bus_lock;), but it's not
implemented at the moment, and will only be compatible with processors sharing
the same code. Add-on processors, such as co-processors, transputer cards, or
DSPs, will know nothing about such a lock emulation. And it would result in
even poorer performance of course !

And yes, I've done intensive benchmarks on the code, as did Denis Vladensko.
I used it daily on my 386sx firewall, which avoided me to recompile my pppd
for this architecture... At this time, I had a wrong gcc+libc combinations
and always got BSWAP instructions all over the code. Although pppd did not
suffer from emulation, I have seen other programs which didn't like it at
all (gzip or bzip2 for example). CPU intensive programs optimized for i686
which use lots of CMOV for example, need about 400 cycles to do a simple CMOV !
this can slow down things to an order of more than 100 when placed in an inner

So to resume, everything can be done through emulation, but that's probably
not what we want as a standard for performance reasons. When I have time, I
may port it to 2.6, but that's not no my priority list.


  reply	other threads:[~2003-07-31  7:17 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-30 13:56 TSCs are a no-no on i386 Jan-Benedict Glaw
2003-07-30 14:18 ` Maciej W. Rozycki
2003-07-30 14:44   ` Jan-Benedict Glaw
2003-07-30 16:58 ` Matthew Garrett
2003-07-30 17:19   ` Alan Cox
2003-07-30 18:10 ` Adrian Bunk
2003-07-30 18:30   ` Mike Fedyk
2003-07-30 18:45     ` Adrian Bunk
2003-07-30 20:01       ` Alan Cox
2003-07-30 20:33         ` Jan-Benedict Glaw
2003-07-30 22:19           ` J.A. Magallon
2003-07-31  6:11             ` Jan-Benedict Glaw
2003-07-30 23:05           ` Alan Cox
2003-07-31 11:11             ` Richard B. Johnson
2003-07-31 11:26               ` Emulating i486+ insn on i386 (was: TSCs are a no-no on i386) Jan-Benedict Glaw
2003-07-31 11:41             ` TSCs are a no-no on i386 Jan-Benedict Glaw
2003-07-31  0:22           ` Adrian Bunk
2003-07-31  6:22             ` Jan-Benedict Glaw
2003-07-31  7:17               ` Willy Tarreau [this message]
2003-07-31 11:38                 ` Emulating i486 on i386 (was: TSCs are a no-no on i386) Jan-Benedict Glaw
2003-07-31 11:51                   ` Alan Cox
2003-07-31 12:14                     ` Jan-Benedict Glaw
2003-07-31 13:01                       ` Jan-Benedict Glaw
2003-07-31 15:09                         ` Martin Schlemmer
2003-07-31 15:33                           ` Jan-Benedict Glaw
2003-08-01  5:37                             ` Martin Schlemmer
2003-07-31 15:12                     ` Jamie Lokier
2003-07-31 15:32                       ` Jan-Benedict Glaw
2003-07-31 15:07                 ` TSCs are a no-no on i386 Jamie Lokier
2003-07-31 15:23                   ` Willy Tarreau
2003-07-31 15:50                   ` Richard B. Johnson
2003-07-31 16:24                     ` Jan-Benedict Glaw
2003-08-06 11:08         ` Pavel Machek
2003-08-06 14:33           ` Maciej W. Rozycki
2003-07-30 20:28       ` Jan-Benedict Glaw
2003-07-30 21:50         ` Petr Vandrovec
2003-07-30 23:10           ` Alan Cox
2003-07-31 15:10             ` Jamie Lokier
2003-07-31 16:01               ` Alan Cox
2003-07-31 18:37                 ` Jamie Lokier
2003-07-31 19:10                   ` Alan Cox
2003-07-31  6:29           ` Jan-Benedict Glaw
2003-07-30 20:27   ` Jan-Benedict Glaw
2003-08-06 16:41 James Bottomley
2003-08-06 16:45 James Bottomley

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030731071719.GA26249@alpha.home.local \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).