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>