Hyperthreading hurts 5.3?

Anthony Atkielski atkielski.anthony at wanadoo.fr
Wed Jan 12 09:46:01 PST 2005

Scott Bennett writes:

SB>      Well, no, not exactly.  The dual-cored CPUs share certain resources
SB> on the chip that are not shared in a multi-CPU situation, and that sharing
SB> means certain operations have to be handled differently.  An MP setup has
SB> separate cache and TLB managment in each CPU ...

What's TLB?

SB> ... whereas P4 w/HT logical processors share this memory management
SB> circuitry. Alteration of a cache line requires notification of the
SB> other processor(s) in an MP situation to mark any corresponding line
SB> in its(their) cache(s) because multiple separate caches are
SB> involved, but notification is not necessary in the P4 w/HT situation
SB> because it's the same cache being seen by both logical processors.
SB>      Alteration/invalidation of TLB entries requires notification to
SB> invalidate in an MP, so that the other CPU(s) can purge any corresponding TLB
SB> entries it(they) may have, but notification is not required in the P4 w/HT
SB> situation because both logical processors are refering to the same TLB.  Again,
SB> unnecessary purging would be a performance hit.
SB>      There must be some special handling of TLB entries in the P4 w/HT that
SB> I haven't seen documented.  (There almost certainly is documentation; I just
SB> haven't seen it yet.)  There must be some way to distinguish between TLB
SB> entries filled per orders of one logical processor from those filled per
SB> orders of the other logical processor.  If there weren't, then one logical
SB> processor would use TLB entries for the address space running on the other
SB> logical processor, which would, of course, be Very Bad.  But, to improve
SB> performance, there should be some way to share TLBs for the case of two
SB> threads running concurrently in the same address space.  If anyone reading
SB> this knows the details of how this is handled in these chips, please post them
SB> here.

From what you say and from what I've read today, it sounds like
hyperthreading comes close to providing two separate processors for
heterogenous system loads (where each hyperthread is using slightly
different processor resources at any given instant), but it may not buy
much of anything for massively parallel compute-bound work, since both
threads may want nearly the same things at the same time and will thus
effectively be forced to spend a lot of time waiting for each other.

Fortunately, my server has a very mixed load, as one would expect for a
generic domain server, so hopefully it will profit from hyperthreading.

And hopefully no weird stuff will happen because I've turned on HT
(although offhand I'm not sure what would happen, unless there are
hidden hardware conflicts or something specific and software-visible
about HT in normal operation that might expose a bug).  I'm not sure
that I see how HT could affect Serial ATA disks, for example, any more
than having two separate physical processors would.


More information about the freebsd-questions mailing list