Re: [FUG-BR] balanceamento entre os cores
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
[FUG-BR] balanceamento entre os cores
Pessoal, Está acontecendo uma coisa aqui estranha e já é a segunda máquina dual processada que está fazendo isso e por isso acredito ser algum tunning que esteja faltando. Primeiro testamos em uma máquina Dual Quad em uma motherboard Intel S1200BTS com 2 processadores de 3.0Ghz. Agora estamos testando em uma motherboard Intel S2600COE com 2 processadores Hexa Xeon de 2.60Ghz. Ambas com HT desabilitado. Quando compilo o sistema tipo um make buildworld, eu reparo que alguns cores ficam com 100% de uso enquanto que outros ficam totalmente liberados. Eu acredito que o ideal seria haver um balanceamento nos cores para que isso não ocorre-se. Quando o equipamento possui 1 processador fica normal, aí pego o HD e coloco nessas 2 máquinas e o que reparo é isso acontecendo pelo top. Existe algum tunning para melhorar isso? Estou usando freebsd 10-stable com kernel sendo cópia do GENERIC e apenas removendo alguns drivers que não estão sendo usados como floppy, scsi, algumas interfaces de rede, essas coisas. []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento entre os cores
Olá, Experimente executar make -jnumero_de_cores buildworld, ele vai criar mais jobs e assim ocupar mais os cores. Att, Felipe N. Oliva Em 25/06/2014 09:14, Marcelo Gondim escreveu: Pessoal, Está acontecendo uma coisa aqui estranha e já é a segunda máquina dual processada que está fazendo isso e por isso acredito ser algum tunning que esteja faltando. Primeiro testamos em uma máquina Dual Quad em uma motherboard Intel S1200BTS com 2 processadores de 3.0Ghz. Agora estamos testando em uma motherboard Intel S2600COE com 2 processadores Hexa Xeon de 2.60Ghz. Ambas com HT desabilitado. Quando compilo o sistema tipo um make buildworld, eu reparo que alguns cores ficam com 100% de uso enquanto que outros ficam totalmente liberados. Eu acredito que o ideal seria haver um balanceamento nos cores para que isso não ocorre-se. Quando o equipamento possui 1 processador fica normal, aí pego o HD e coloco nessas 2 máquinas e o que reparo é isso acontecendo pelo top. Existe algum tunning para melhorar isso? Estou usando freebsd 10-stable com kernel sendo cópia do GENERIC e apenas removendo alguns drivers que não estão sendo usados como floppy, scsi, algumas interfaces de rede, essas coisas. []´s Gondim - 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
Re: [FUG-BR] balanceamento entre os cores
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. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento entre os cores
Em 25/06/2014 09:14, Marcelo Gondim escreveu: Pessoal, Está acontecendo uma coisa aqui estranha e já é a segunda máquina dual processada que está fazendo isso e por isso acredito ser algum tunning que esteja faltando. Primeiro testamos em uma máquina Dual Quad em uma motherboard Intel S1200BTS com 2 processadores de 3.0Ghz. Agora estamos testando em uma motherboard Intel S2600COE com 2 processadores Hexa Xeon de 2.60Ghz. Ambas com HT desabilitado. Quando compilo o sistema tipo um make buildworld, eu reparo que alguns cores ficam com 100% de uso enquanto que outros ficam totalmente liberados. Eu acredito que o ideal seria haver um balanceamento nos cores para que isso não ocorre-se. Quando o equipamento possui 1 processador fica normal, aí pego o HD e coloco nessas 2 máquinas e o que reparo é isso acontecendo pelo top. Existe algum tunning para melhorar isso? Estou usando freebsd 10-stable com kernel sendo cópia do GENERIC e apenas removendo alguns drivers que não estão sendo usados como floppy, scsi, algumas interfaces de rede, essas coisas. []´s Gondim Marcelo, li em algum canto em algum momento da minha vida algo que dizia o seguinte: -Se o processo ficar mudando de núcleo muitas entradas da cache serão invalidadas. Tipo, se o processo ficar migrando de núcleo todo o trabalho que a cache teve para armazenar as entradas mais utilizadas será perdido. Não sei se isto é sempre válido mas talvez seja o caso. []'s -Otacílio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento entre os cores
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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento entre os cores
-- 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. :-) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento entre os cores
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
