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" 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 wrote:
> >
> >> Em 25/06/2014 09:30, Renato Botelho escreveu:
> >>> On Jun 25, 2014, at 9:23, Felipe N. Oliva
> wrote:
> Olá,
>
> Experimente executar make -j 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
