Hyperthreading hurts 5.3?

[Anthony Atkielski]

Giorgos Keramidas writes:

GK> The 'separate file' is NOTES.  This file is actually the complete
GK> reference of options that the kernel supports, so it's not like the SMP
GK> option is hidden or something.

I must have a magic special version of FreeBSD:

# cd /usr/src/sys/i386/conf
# grep SMP *
NOTES:# SMP OPTIONS:
NOTES:# The apic device can be used in both UP and SMP kernels, but is required
NOTES:# for SMP kernels.  Thus, the apic device is not strictly an SMP option,
NOTES:# but it is a prerequisite for SMP.
NOTES:# Be sure to disable 'cpu I386_CPU' for SMP kernels.
NOTES:# Enabling this with an SMP kernel will cause the kernel to be unusable.
NOTES:options   I4B_SMP_WORKAROUND
SMP:# SMP -- Generic kernel configuration file for FreeBSD/i386 SMP
SMP:# $FreeBSD: src/sys/i386/conf/SMP,v 1.5.4.1 2004/10/23 20:04:00 kensmith Exp $
SMP:options     SMP
#

The "options SMP" appears only in a file called SMP on my system.

GK> Because it's not always a 'profit'.
GK>
GK> The locking and synchronization overhead is not always negligible.

My experience with multiprocessing on other systems is that this
overhead is rarely an issue.  For single-threaded compute-bound user
processes and occasionally for some similarly-designed OS processes it
sometimes makes a difference; usually there's a net gain, though.

At some specific number of processors (often 5 or more, but it depends
on many things), the additional overhead associated with managing yet
another processor (including hardware and software contention) causes
global performance to diminish rather than increase.  But I'd be very
surprised to see that on any OS or platform with only two processors.

There are also some key advantages to having more than one processor,
such as the fact that the system is much more likely to remain
responsive if a (typical single-threaded) process gets stuck in a loop.

-- 
Anthony