Date: Sat, 31 Oct 1998 14:18:36 -0600 From: Dan Nelson <dnelson@emsphone.com> To: Steve Friedrich <SteveFriedrich@Hot-Shot.com>, "ajk@mastigo4.demon.co.uk" <ajk@mastigo4.demon.co.uk>, "Christopher J. Michaels" <cjm2@earthling.net>, Dean Hollister <dean@odyssey.apana.org.au> Cc: "questions@FreeBSD.ORG" <questions@FreeBSD.ORG> Subject: Re: Cyrix 6x86 CPU Message-ID: <19981031141836.B2302@emsphone.com> In-Reply-To: <199810311552.KAA14228@laker.net>; from "Steve Friedrich" on Sat Oct 31 10:51:05 GMT 1998 References: <199810311552.KAA14228@laker.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Oct 31), Steve Friedrich said:
> On Sat, 31 Oct 1998 10:35:03 -0500, Christopher J. Michaels wrote:
>> Well of course THAT's going to work, you have all the processors
>> listed there.
>>
>> The one that you need for the Cyrix 6x86 CPU is the following. YES
>> that's the 486, the kernel will panic if you define only the 586.
>>
>> cpu "I486_CPU"
>>
>> My understanding is that by listing all of those processor types,
>> the kernel is not optimized for your specific processor and is a bit
>> slower.
>
> I read (somewhere) that the best improvement comes from deleting the
> 386 type.
Lets settle this once and for all. Do a "find /usr/src/sys | xargs
egrep -a I.86_CPU" and follow along:
o The only 386-specific code run after the kernel probes is in
i386/i386/pmap.c and support.s, and that is wrapped by an if
(cpu_class == CPUCLASS_386), or assembly equivalent.
o The only 486-specific code in the kernel is in initcpu.c, which
optimizes CPU registers for certain 486-clone chips.
o The only 586-specific code is either also 686-specific code, or
exists to handle the F00F bug, or enables a fast kernel bcopy during
kernel probes (npx.c).
o The only 686-specific code is either also 586-specific code, or is in
initcpu.c, which optimizes CPU registers for certain 686-clone chips.
o The joint 586/686-specific code handles the high-precision CPU clocks
internal to the CPUs, and is always wrapped by an if (CPU_CLASS ==
CPUCLASS_586 || CPUCLASS_686).
So, the speed loss due to including unnecessary CPU types in a kernel is:
I386_CPU: one compare/jump every time invltlb_*pg(),
generic_copyout(), suword(), or subyte() is called
I486_CPU: none
I586_CPU alone: not sure when the F00F code gets triggered
I686_CPU alone: none
I586|I686: one compare/jump every time microtime() or
CPU_CLOCKUPDATE() is called
Even though generic_copyout() and microtime() are heavily-used
functions, their overall complexity swamps the effects of one extra
compare/jump.
So for all but the most rabid performace freaks that can sense when a
branch is predicted wrong or when a pipeline stalls, including all
possible CPU types will make absolutely no difference.
-Dan Nelson
dnelson@emsphone.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981031141836.B2302>