Compilando kernel com parâmetro -j
Então, num dia sem muita coisa pra fazer, resolvi verificar a compilação do kernel com dados mais concretos e monitoração dos resultados.
Já faz anos que compilo meus kernels e sistemas com a utilização do parâmetro “-j 8” ou “-j 12”. Esse parâmetro, passado ao GCC, faz uso de multithreads em máquinas com mais de um processador ou processador multicore, como esse Intel Core i3 que tenho no laptop.
Mas sempre usei esse parâmetro quase que como dogma, sem muita certeza de sua eficiência. Aliás, com uma pequena ideia de eficiência já que, sem o uso do mesmo, o tempo de compilação era mais demorado. Mas tudo muito de “sentimento”, sem nenhuma comprovação.
Então, num desses dias sem muita coisa pra fazer (pequena metira: estava lotado de coisas pra terminar, mas decidi fazer isso pra limpar um pouco a mente), resolvi verificar essa compilação com dados mais concretos e monitoração dos resultados. Fiz o seguinte programa em python pra ficar compilando um kernel que já estava configurado e que eu tinha certeza que compilava sem problemas, com as threads indo de 1 a 20:
#! /usr/bin/python
# make clean; time make-kpkg -j 4 --initrd kernel_image
import os
import time
#print time.time()
OUTPUT = "/tmp/kernel_results.csv"
FD = open(OUTPUT, "w")
for TH in xrange(1,21):
print "Threads:", TH
print "\tlimpando..."
os.system("make clean")
t_0 = time.time()
os.system("make-kpkg -j " + str(TH) + " --initrd kernel_image")
t_1 = time.time()
total_time = t_1 - t_0
msg = "Threads: %d in %0.2f s" %(TH, total_time)
print msg
FD.write(str(TH) + "," + str(total_time) + "\n")
FD.flush()
Então deixei o sistema rodando. Eu costumo usar o “make-kpkg”, do pacote kernel package, que já gera para mim o pacote DEB para instalação.
Ao final, os resultados foram os seguintes:
A troca de contextos de processos realmente aumentou com o aumento de threads. Por isso o sistema fica tão lento.
O sistema ficou com uso de CPU intenso, mas sem crescimento gradual (isso eu já achei estranho).
As interrupções de mudança de contexto também ficaram iguais, onde eu esperava um valor em degraus.
Mas a carga do sistema, load average, aumentou realmente em degrau, acompanhando a quantidade definida no “-j”. Isso era esperado e é sempre notado, pois o computador fica super lento.
Porém, o melhor ficou pro final: a análise do tempo pela quantidade de threads.
O tempo diminuiu conforme a quantidade de threads que aumenta até… 3??? O processador Intel Core i3 é um multicore de 4 cores, eu esperava ao menos um melhor desempenho até 4 threads, mas dá pra ver bem claro que o sistema estabiliza em 3.
Ou seja, usando “-j 8” ou “-j 12” só serve para aumentar a carga da CPU, aumentando as trocas de contextos, mas não significam nem melhora nem otimização da compilação. Pelo contrário. Então o melhor é saber o máximo que a CPU realmente aguenta antes de aplicar cegamente parâmetros para *melhorar* o desempenho do sistema. E monitorar os resultados!
Atualização: Sun Feb 3 20:34:35 BRST 2013
Conforme o pedido do Erick Tostes (@ericktostes no twitter), estou incluindo o meu /proc/cpuinfo.
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz stepping : 2 microcode : 0x9 cpu MHz : 933.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 4255.62 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz stepping : 2 microcode : 0x9 cpu MHz : 933.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 4255.62 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz stepping : 2 microcode : 0x9 cpu MHz : 933.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 2 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 4255.62 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz stepping : 2 microcode : 0x9 cpu MHz : 933.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 2 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 4255.62 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
trabalha em telecomunicações na Ericsson. Formado em engenharia elétrica pela UFSC e com MBA em gestão estratégica de TI pela FGV, trilha o mundo do software livre desde 1997, passando por Linux em geral, Debian e FreeBSD. Atualmente, se interessa mais pelo lado de startups do software livre e menos por código, mas sempre dá uma escapadinha para programar em Python.
