HTT on current
Daniel C. Sobral
dcs at tcoip.com.br
Mon Aug 25 10:14:30 PDT 2003
David O'Brien wrote:
> On Mon, Aug 25, 2003 at 08:27:46AM -0600, Scott Long wrote:
>
>>Since HTT can lead to performance degradation in some (many?) cases,
>>the second logical CPU's are halted by default. They are enabled,
>>however, in order for interrupt routing to work right. Work is ongoing
>>to make an HTT-aware scheduler, and make the enabling of the logical
>>cores optional.
>
>
> I've heard this several times and don't doubt it, but it would be nice to
> know more about the issue. What type of cases? What benchmarks have
> been run showing this?
Well, I haven't actually seen any case where there was a performance
gain instead of degradation.
There are two problems with HTT. First, L1/L2 cache issues. Second, the
virtual CPUs are not independent, and there are many cases where
instructions in one virtual CPU stall the other. So take, for example,
the case of a userland application on CPU0 stalling the kernel on CPU1.
The case where HTT presents gains are for applications compiled in a way
to maximize HTT benefits and minimize HTT stalling. It would be perhaps
be best to restrict HTT usage to threads of a same application, and
avoid them at all when in kernel. Intel disagrees, of course, and I
haven't been a low level person for many, many years, so YMMV. :-)
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
VIVO Centro Oeste Norte
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: Daniel.Capo at tco.net.br
Daniel.Sobral at tcoip.com.br
dcs at tcoip.com.br
Outros:
dcs at newsguy.com
dcs at freebsd.org
capo at notorious.bsdconspiracy.net
A raccoon tangled with a 23,000 volt line today. The results
blacked out 1400 homes and, of course, one raccoon.
-- Steel City News
More information about the freebsd-current
mailing list