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