Date: Sat, 20 Mar 2010 01:27:24 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI <delphij@freebsd.org> Subject: Re: svn commit: r205307 - head/sys/i386/conf Message-ID: <20100320002555.I1181@delplex.bde.org> In-Reply-To: <201003190759.56385.jhb@freebsd.org> References: <201003190116.o2J1Gr2v094129@svn.freebsd.org> <201003190759.56385.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Mar 2010, John Baldwin wrote: > On Thursday 18 March 2010 9:16:53 pm Xin LI wrote: >> Author: delphij >> Date: Fri Mar 19 01:16:53 2010 >> New Revision: 205307 >> URL: http://svn.freebsd.org/changeset/base/205307 >> >> Log: >> SSE is enabled by default about 5 years ago so there is no point pretending >> that we support I486 and I586 CPUs in the GENERIC kernel, users wants these >> support would have to build a custom kernel to explicitly disable SSE >> anyways. >> >> MFC after: 1 month > > No, this is wrong. Revert this. We do _not_ unconditionally use SSE in the > kernel. GENERIC should run just fine on a 486. If it doesn't, that should be > fixed, but I have not seen any reports to the contrary. Indeed. This doesn't even break the non-SSE case, since it doesn't remove I686_CPU or any of the code that dynamically chooses whether to use SSE. Most 686's don't have SSE, since a 686 is an old name for a PentiumPro or maybe a Pentium2 and these don't have SSE (not sure about the Pentium2, but my old Celeron is Pentimum2-class and it only has FXSR). However, we keep using this old name for all generations of i386's after i586, even for generations that are really HAMMERs. Thus the static configuration related to I*86_CPU is almost usless: it controls only couple of options for i486 and i586, with the more complicated and costly configuration for post-i586 being handled dynamically. Omitting I486_CPU and I586_CPU thus has very little effect except breaking i486 and i586, and having these options does little except support this foot-shooting. The effect of I486_CPU is especially small. It is: - statically disable use of the TSC in the bogus get_cyclecount() API. Although the TSC is dynamically configured elsewhere, this function wants to use the TSC without any dynamic tests, so it is uses static configuration for efficiency. - avoid compiling in functions to initialize a 486. There is dynamic code to use these functions as needed, but this optimization saves a few hundred if not a few thousand bytes. - panic if the CPU is an i486, since the necessary extra support for an i486 (just the above 2 features) is not present. I586_CPU gives a little more. E.g., support for fixing the F00F hardware bug on some Pentium1's. Again there is dynamic configuration for this but a few hundred bytes are saved by not compiling it in. > In general we do not > use any floating-point / MMX / SSE instructions in the kernel as our FPU > context-saving code doesn't support it. Actually, we do, sort of. We use the fxsave and fxrstor instructions, if available, in the context-saving code itself. These are closely related to SSE, if not part of SSE. They are in different cpuid flags (FXSR instead of SSE*), but the dynamic code for using them is configured by the same ifdefs as for using SSE. My old Celeron with FXSR thus uses fxsave/fxrstor but not SSE proper (even in userland). > All the x86 world is not rack-mounted 64-bit servers. We should not remove > support for non-686 CPUs for no good reason. 486 CPUs have cmpxchg and xadd > so are perfectly adequate. Why do we still have CPU_DISABLE_CMPXCHG then? It was mainly for i386, and is now documented as being useful for old vmware, but hopefully vmware has been replaced by not-so-old vmware, qemu, kqemu, virtualbox,... and these support cmpxchg. The configuration of cmpxchg and a couple of other things is only static. SSE has both dynamic and static configuration. Its static configuration is obfuscated for historical reasons. It used to be a positive option but now it is a negative option. The positive option is set in all 2 files that use SSE (actually only FXSR?) by the following ifdef: % #if !defined(CPU_DISABLE_SSE) && defined(I686_CPU) % #define CPU_ENABLE_SSE % #endif So CPU_ENABLE_SSE is the default, but the dynamic code for using it can be not compiled in either by configuring CPU_DISABLE_SSE or by not configuring I686_CPU. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100320002555.I1181>