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 -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. > > > > :-) > > > 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
