mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: <tigran@veritas.com>
Cc: "Justin Piszcz" <jpiszcz@hotmail.com>, <linux-kernel@vger.kernel.org>
Subject: RE: Linux Kernel Microcode Question
Date: Fri, 19 Mar 2004 15:16:33 -0800	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKKEGHLDAA.davids@webmaster.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0403191721110.3892-100000@einstein.homenet>



> On Thu, 18 Mar 2004, David Schwartz wrote:
> > 	It is at least theoeretically possible that a microcode
> > update might cause
> > an operation that's normally done very quickly (in dedicated
> > hardware) to be
> > done by a slower path (microcode operations) to fix a bug in
> > the dedicated
> > hardware

> Did you dream that up or did you read it somewhere? If the latter, where?

	Since you agree with me, I'm not sure I understand why it matters.

> All operations are done by "dedicated hardware" and microcode DOES modify
> that hardware, or rather the way instructions are "digested". So, applying
> microcode doesn't make anything slower per se, it's just replacing one
> code sequence with another code sequence. If a new code happens to be
> slower than the old one then of course the result will be slower, but the
> reverse is also true. When you fix a bug in a particular software why
> should a bugfix be apriori slower than the original code? Think about it.

	I didn't say it would have to be slower. I said it might force an operation
to be done by a slower path. You seem to agree with me that the new code
could happen to be slower than the old one.

	As for why a bugfix would be likely to be slower than the original code,
it's because of the limitations of the microcode update. The microcode
update can't change wiring, so if the problem is in wiring, then the
microcode would have to bypass that wiring. One would presume the wiring was
there for a reason -- to accelerate something.

> So please do not spread misinformation that applying microcode makes
> something slower. If anything, it should make things faster, as long as
> the guys at Intel are writing the correct (micro)code.

	I'm simply saying that it's at least theoretically possible that a
microcode update might increase correctness at the expense of performance.
The only contrary position would be that such a thing is impossible. The
position I'm refuting is that there is not, even in theory, any downside to
performing a microcode update.

	By the way, there is reason to believe that microcode updates can redirect
into microcode operations normally performed in hardware (though I know for
sure only that certain exceptions can be handled this way on at least one
Intel processor); however, I think it would be rather foolish to prefer
speed over correctness. I have also heard of microcode updates that
supposedly fixed performance problems.

	DS



  reply	other threads:[~2004-03-19 23:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-18 16:40 Justin Piszcz
2004-03-18 16:59 ` Dave Jones
2004-03-18 17:13   ` David Schwartz
2004-03-19 17:27     ` Tigran Aivazian
2004-03-19 23:16       ` David Schwartz [this message]
2004-03-22 11:55         ` Tigran Aivazian
2004-03-22 15:51       ` Timothy Miller
2004-03-22 15:40         ` Tigran Aivazian
2004-03-22 16:19           ` Timothy Miller
2004-03-22 19:14           ` David Schwartz
2004-03-22 20:58             ` John Bradford
2004-03-22 16:13         ` Richard B. Johnson
2004-03-22 16:51           ` Timothy Miller
2004-03-22 17:14             ` Richard B. Johnson
2004-03-18 16:59 ` Richard B. Johnson
2004-03-18 17:07   ` Robert Love
2004-03-19  0:16   ` Bill Davidsen
2004-03-19 12:56     ` Richard B. Johnson
2004-03-18 22:20 ` Tigran Aivazian
2004-03-18 17:19 Nakajima, Jun

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=MDEHLPKNGKAHNMBLJOLKKEGHLDAA.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=jpiszcz@hotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tigran@veritas.com \
    /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

all inboxes | Powered by JetHome®