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
Message-ID: <MDEHLPKNGKAHNMBLJOLKKEGHLDAA.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <Pine.LNX.4.44.0403191721110.3892-100000@einstein.homenet>
Reply-To: davids@webmaster.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2699
Lines: 58


> 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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/