No SQLOS, um agendador é criado para cada processador lógico que o SQL Server vê. Com o hyperthreading ativado, isso equivale a duplicar os agendadores. Um dos propósitos do SQLOS é minimizar e impedir que ocorra a troca de contexto, razão pela qual apenas um agendador é criado para cada processador lógico. Uma vez que o SQLOS cria os agendadores, o número total de trabalhadores é dividido entre os agendadores. O SQLOS implementa uma forma de planejamento cooperativo em que os operadores geram o planejador, já que ele requer recursos indisponíveis ou alcança seu quantum de execução, permitindo que outros funcionários executem no planejador. Isso mantém o contexto mudando para um mínimo, já que o agendador está fazendo o trabalho e eles estão ligados um a um.
Compreendendo esse plano de fundo, o hyperthreading funciona um pouco ao contrário de como o SQLOS é especificamente projetado para funcionar. Especificamente, o paralelismo pode ser problemático com o hyperthreading e pode resultar em esperas altas do CXPACKET, já que o SQLOS pode tentar executar uma consulta no DOP 8 sobre o que é um sistema DOP 4 da realidade. Se a utilização da CPU estiver baixa, talvez você não perceba, mas quanto maior a utilização da CPU, mais problemático ela pode se tornar. Recentemente, tive uma discussão no twitter sobre isso, e o consenso foi "Depende" de saber se isso ajudaria ou prejudicaria.
Se você espera muito sinal no seu servidor, mas tem pouca utilização da CPU, pode ver o benefício de ativar o hyperthreading, que duplicará seus agendadores internos e distribuirá mais os funcionários, o que significa que eles não esperarão para executar a fila executável por tanto tempo. No entanto, se a sua carga de trabalho utilizou muito o paralelismo que o CXPACKET aguenta em sys.dm_os_wait_stats, você pode desabilitar o hyperthreading para ver se ele reduz suas esperas.