Alfred Perlstein wrote:
> * Dorr H. Clark <dclark@applmath.scu.edu> [020522 09:58] wrote:
> > I don't have access to a fancy Xeon, I just have
> > a PIII dual-banger, so I'm relying on the list traffic.
> > To summarize the past two months:
> >
> > On Thu, 14 Mar 2002, John Baldwin wrote:
> > On Thu, 14 Mar 2002, Terry Lambert wrote:
> > On Tue, 23 Apr 2002, FiberOps wrote:
> > On Tue, 23 Apr 2002, John Baldwin wrote:
> > On 23-Apr-2002 FiberOps wrote:
> >
> > This final message was not followed up except by me,
> > although someone else informed me that while the CPUs
> > launch, FreeBSD can't run processes on them.
> >
> > So I thought I'd try to stir up an answer to the original question:
> >
> > For the latest Xeon motherboards, does FreeBSD 4.x stable
> > support hyperthreading? If not, does the current TOT?
> > If not, why not? Is gcc an issue or not? If gcc is an issue,
> > would this be an obstacle for all gcc-based OSes,
> > not just FreeBSD, most prominently among these Linux?
> >
> > Clear answers gratefully appreciated,
>
> I'm glad you chose to take the word of a couple of people
> that have never used a hyperthreading board above what I've
> already told you.
>
> Here's what I know:
> The additional CPUs probe.
>
> A benchmarking utility reports equivelant performance to a 4 way
> machine.
According to the Intel documentation I read, hyperthreading is not
the same thing as simply having the extra CPUs on the same die (which
is what you seem to be implying it is). Here is the reference:
http://www.intel.com/design/Xeon/Whitepaper/WhitepaperNBHT.htm
Unfortunately, the other references are the victims of a broken CGI
right now (the compiler references from me, quoted in his posting).
As a summary:
o You must specifically set the thread stack base in order
to optimize performance (FreeBSD does not do this)
o You need explicit scheduler support to distinguish between
logical and physical processors (FreeBSD does not do this;
not really a big relative loss, since FreeBSD also does not
support SMP CPU affinity, so there's no reason for stronger
affinity between logical CPUs within the same CPU)
o Threaded programs should be built by a compiler which is
cognizant of the L1 cache effects, such that there are
not pipeline stalls -- roughtly equivalent to the instrcution
reordering optimizations in the DEC Alpha compiler (FreeBSD's
compiler does not do this)
o Code co-units need to have their code generated interleaved
so that they can be co resident in the single L1 cache,
without flushing stalls when simultaneously operating two
or more logical CPUs (FreeBSD's compiler does not do this)
o Inter-logical CPU locking can deadlock, unless you pipeline
your spinlocks (FreeBSD locks are heavy weight)
o Use of the PAUSE instruction is required to delay operations
without effecting other logical processors (FreeBSD does not
do this)
See also the "Intel Pentium 4 and Intel Xeon Processor Optimization
Manual" (that's the one that Intel's CGI script complains about right
now) and http://cedar.intel.com/cgi-bin/ids.dll/topic.jsp?catCode=CDN .
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message