Em 25/06/2014 12:35, Patrick Tracanelli escreveu:
>
> --
> Patrick Tracanelli
>
> FreeBSD Brasil LTDA.
> Tel.: (31) 3516-0800
> [email protected]
> http://www.freebsdbrasil.com.br
> "Long live Hanin Elias, Kim Deal!"
>
> On 25/06/2014, at 12:16, Marcelo Gondim <[email protected]> wrote:
>
>> Em 25/06/2014 09:30, Renato Botelho escreveu:
>>> On Jun 25, 2014, at 9:23, Felipe N. Oliva <[email protected]> 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
