Com -jN e esse N maior que o número de CPUs só faz o sistema perder mais
tempo com a mudança de contexto.
./helio
On Jun 25, 2014 4:37 PM, Marcelo Gondim gon...@bsdinfo.com.br wrote:
Em 25/06/2014 12:35, Patrick Tracanelli escreveu:
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316...@sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
Long live Hanin Elias, Kim Deal!
On 25/06/2014, at 12:16, Marcelo Gondim gon...@bsdinfo.com.br wrote:
Em 25/06/2014 09:30, Renato Botelho escreveu:
On Jun 25, 2014, at 9:23, Felipe N. Oliva fel...@felipeoliva.eti.br
wrote:
Olá,
Experimente executar make -jnumero_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.
:-)
hehehe valeu Patrick pela explicação e agora fiquei mais tranquilo
quanto à isso. :)
Grande abraço povo!
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
