svn commit: r205307 - head/sys/i386/conf

David Schultz das at FreeBSD.ORG
Fri Mar 19 21:55:24 UTC 2010

On Sat, Mar 20, 2010, Bruce Evans wrote:
> 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.

Agreed, these options make very little difference right now, but
they *could* have a bigger impact.  Other operating systems have
completely deprecated older CPUs in order to take better advantage
of new features than FreeBSD does.  For instance, Solaris 10
requries CMPXCHG8B, which is needed to implement correct lock-free
queues that are efficient enough to be useful.  Supposedly this is
a big win under high contention.  Windows XP and later also
require CMPXCHG8B.

The catch, of course, is that if you write a scheduler to take
advantage of lock-free queues, expensive emulation (spinlocks)
will be required to make it work on hardware without the necessary
support.  Merely *having* a supported I486_CPU knob makes design
choices like these seem unattractive.  Another concrete example:
We don't properly save/restore the SSE state in setjmp() on i386
because it's cumbersome to do this and without breaking older CPUs.

More information about the svn-src-head mailing list