From owner-freebsd-questions Sat Oct 31 12:18:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10446 for freebsd-questions-outgoing; Sat, 31 Oct 1998 12:18:59 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10439 for ; Sat, 31 Oct 1998 12:18:55 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.1/8.9.1) id OAA02921; Sat, 31 Oct 1998 14:18:36 -0600 (CST) Date: Sat, 31 Oct 1998 14:18:36 -0600 From: Dan Nelson To: Steve Friedrich , "ajk@mastigo4.demon.co.uk" , "Christopher J. Michaels" , Dean Hollister Cc: "questions@FreeBSD.ORG" Subject: Re: Cyrix 6x86 CPU Message-ID: <19981031141836.B2302@emsphone.com> References: <199810311552.KAA14228@laker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.3i In-Reply-To: <199810311552.KAA14228@laker.net>; from "Steve Friedrich" on Sat Oct 31 10:51:05 GMT 1998 X-OS: FreeBSD 2.2.7-STABLE Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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