[FUG-BR] balanceamento entre os cores

[Patrick Tracanelli]

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

On 25/06/2014, at 12:16, Marcelo Gondim <gondim em bsdinfo.com.br> wrote:

> Em 25/06/2014 09:30, Renato Botelho escreveu:
>> On Jun 25, 2014, at 9:23, Felipe N. Oliva <felipe em felipeoliva.eti.br> wrote:
>>> Olá,
>>> 
>>> Experimente executar make -j<numero_de_cores> buildworld, ele vai criar
>>> mais jobs e assim ocupar mais os cores.
>> O indicado é -jN, onde N é o dobro do número de cores, desde que N seja <= 16. Com mais de 16 jobs a eficiência é afetada.
>> 
>> 
> Opa Pessoal,
> 
> Tentei com -j16 porque aqui são 12 cores e piorou a situação rsrsrsrrs
> Ficaram vários cores com quase 100% só se o clang tá chupando à rodo na 
> compilação rsrsrsrsrs
> 
> Bem vou fazer outros testes aqui pessoal. :D

Mas é isso que você fez. O -jN paraleliza a compilação em N jobs de objetos pra depois que estiverem prontos juntar tudo e linkar no objeto final.

Não, diferente do que você acha, não é ruim um ou N core ficarem 100% em uso enquanto os outros ficam IDLE. Se existem poucas threads ou o job é monothread o máximo de CPU que ele pode consumir é uma mesmo (por thread). Nesse caso as outras ficam IDLE e a função do escalonador do kernel é por qualquer outra coisa pra processar nos que estiverem IDLE mantendo a CPU ocupada essencialmente pra aquela função.

Processos que eventualmente ja estavam naquela CPU que agora está no talo, se mantém nela enquanto estão em estados de execussão diferente de RUN. Mas assim que saem de espera e vão pra RUN vão ser mudados de CPU pra uma mais IDLE.

Essa mudança é a famosa troca de contexto e ela é pesada, perde-se vários ciclos de processamento só fazendo a troca de contexto. Envolve gravar registrar, restaurar, mudar estado do processo na run queue e monitorar isso tudo.

Ou seja se acontecesse o que você quer, ficar alternando entre as CPUs o processamento, não teria vantagem e ainda teria toda a perda de tempo e esforço pra fazer a troca de contexto.

O que acontece e as vezes achamos que troca de CPU são processos multithread que ocupam CPU1 depois CPU3 depois CPU4 mas nesses casos as threads finalizaram e são iniciadas em outras CPU, dando a impressão que o mesmo “processo” esta mudando de CPU, mas são threads independentes. Em outros casos como Apache com Worker ou qmail ou qualquer server que instância múltiplas cópias de si mesmo voce vai reparar que são PIDs distintos nas CPUs, ou seja outro processo, não há também a troca de CPU à esmo.

Ou seja deixa como ta que ta certo hehehe ;-) E se quiser tirar melhor proveito de TODAS as CPUs ai sim usa -jNCPU ou -jN onde N pode ser menos CPU do que voce tem, -j8 vai por objetos paralelos em 8 CPUs deixando as outras 8 livres pro que for necessário na demanda autênca do seu server.

Eu pessoalmente nunca vi ganho realmente justificável em usar acima de -j4 no buildkernel e buildworld. Mas claro que usando apenas a lógica -j8 vai ser mais rápido que -j4 hehehe mas pra mim nunca foi, talvez porque nunca medi com outra forma que não seja time -h hehehe, mas o ganho é irrelevante, ao menos com HDD. Já com SSD acho que você tem menos gargalos no processo todo.

:-)