public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: jw schultz <jw@pegasys.ws>
To: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] CMOV emulation for 2.4.19-rc1
Date: Tue, 2 Jul 2002 17:36:36 -0700	[thread overview]
Message-ID: <20020702173636.A13790@pegasys.ws> (raw)
In-Reply-To: <20020702200005.GA29557@pcw.home.local>; from willy@w.ods.org on Tue, Jul 02, 2002 at 10:00:05PM +0200

On Tue, Jul 02, 2002 at 10:00:05PM +0200, Willy TARREAU wrote:
> > Can you code up a "dummy" emulator (which just ignores
> > any invalid opcode by doing eip+=3) and compare trap times
> > of your emulator and dummy one for, say, CMOVC AL,AL?
> > (with carry flag cleared)
> 
> The dummy emulator costs exactly 296 cycles (stable) on my
> k6-2/450. It only adds 3 to eip then returns.
> 
> To check this, I compared 1 million iteriations of 10
> consecutive cmove %eax,%eax with as much lea 0(%eax),%eax
> (1 cycle, RAW dependancy, not parallelizable), and the
> difference was exactly 660 ns/inst (297 cycles).
> 
> That said, I agree with you that it's worth optimizing a
> bit, at least to stay closer to 300 cycles than to 450.
> But that won't make emulated machines fast anyway.
> 
> One interesting note: I tested the prog on a VIA C3/533
> Mhz. One native cmove %eax,%eax costs 56 cycles here ! (at
> first, I even thought it was emulated). It's a shame to see
> how these instructions have been implemented. May be they
> flush the pipelines, write-backs, ... before the instruction.
> BTW, cmov isn't reported in cpu_flags, perhaps to discourage
> progs from using it ;-)
> 
> I will recode the stuff, and add two preventive messages:
>  - at boot time : "warning: this kernel may emulate unsupported instructions. If you
>    find it slow, please do dmesg."
>  - at first emulation : "trap caught for instruction XXX, program XXX."

Too often the "it seems slow" complaint comes after weeks or
even months of uptime.  How about the message every n times
an emulation is required.

	  if(!(emulation_count++ & 0xHHHH))
		printk(...);

wouldn't add too much more overhead than

	if (!emulation_notice)
	{
		emulation_notice = 1;
		printk(...);
	}

after all this is only supposed to happen under rescue
situations.  That way it will be sure to be in the logs and
maybe even on the console and we won't have to hunt for it.

Also, the message should say you are doing instruction
emulation.  "wrong model cpu, emulating instruction XXX" I
doubt indicating the program is helpful unless the tracking
is done per task or the printk every time you emulate.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

  reply	other threads:[~2002-07-03  0:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-30  4:39 [ANNOUNCE] CMOV emulation for 2.4.19-rc1 Willy TARREAU
2002-07-01 13:58 ` Denis Vlasenko
2002-07-01 13:03   ` willy tarreau
2002-07-01 15:55     ` Bill Davidsen
2002-07-02 10:46       ` Denis Vlasenko
2002-07-02  6:31         ` willy tarreau
2002-07-02 12:03           ` Denis Vlasenko
2002-07-01 16:25     ` Gabriel Paubert
2002-07-01 17:08       ` willy tarreau
2002-07-01 18:16     ` Denis Vlasenko
2002-07-01 13:25       ` willy tarreau
2002-07-02 20:00       ` Willy TARREAU
2002-07-03  0:36         ` jw schultz [this message]
2002-07-18 19:15           ` Robert de Bath
2002-07-18 20:44             ` jw schultz
2002-07-01 18:25 ` Denis Vlasenko

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=20020702173636.A13790@pegasys.ws \
    --to=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    /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