Performance - Linus-style
Só um teaser: compilação de todo o kernel em 16 segundos...
-- Linus Torvalds
- o blogue de elmig
- Clique Iniciar Sessão ou registar-se para colocar comentários
Só um teaser: compilação de todo o kernel em 16 segundos...
-- Linus Torvalds
Comentários
A pergunta pode ser
A pergunta pode ser estúpida e elementar, mas como é que o linus mete o kernel todo na memória? Presumo que sejam necessárias grandes quantidades :)
Ele dá (penso eu) 2
Ele dá (penso eu) 2 dicas:
- o disco é lento blá blá blá, evitar disco, usar memória...
Ele menciona toneladas de memória e se calhar não está a brincar.
Uma das facetas do kernel Linux é permitir 'gazillions' de memória e fazer a gestão disso.
Se alguém tem de ter toneladas de memória tem de ser o criador-ditador-gestor do kernel Linux.
Não faço ideia quanta terá mas quando nós tivemos pela primeira vez 1 GB de RAM já ele deveria ter dezenas de GBs.
O 'brinquedo' mostrado em baixo, apesar de não ser 'novo' já foi desenvolvido para suportar 128 GB de RAM, embora também existam modelos com 64 GB.
RAMdisks? Ou talvez memória suficiente para ter sempre o repositório git do kernel [1] todo em cache sem nunca precisar de o despejar para a swap ('~# echo "0" /proc/sys/vm/swapinness')?
Kernel 'afinado' para nunca ir à swap, e outros parâmetros que nós, mortais :), desconhecemos?
Tudo é possível, o homem desenvolve o seu próprio kernel...
- make -j16
Isto faz supor que tem 16 threads disponíveis.
Ora como além da gestão de memória o kernel Linux também é conhecido por conseguir lidar com (quase) infinitos processadores e threads suponho que ele terá vários processadores, com várias threads, á espera do compilador... 4 processadores? 16 threads?
Talvez um 'brinquedo' [2] deste tipo? 4 Opterons da AMD, cada um deles com 4 cores? Ou outra coisa idêntica da Intel com Xeons?
Obviamente, é apenas suposição, mas é uma hipótese.
Não me admirava nada que até tivesse 'blades' para testar o kernel. E até que os fabricantes lhos disponibilizassem para que ele desenvolva para essas máquinas. E não ficaria surpreendido se tivesse hardware mais exótico, e não comercializado no mercado (protótipos), disponibilizado pelos fabricantes para 'test-drive'.
1 - git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
2 - http://www.tyan.com/product_board_spec.aspx?pid=619
--
"No ínicio não havia nada e Ele disse: apt-get install light"
Penso que o normal do make
Penso que o normal do make -j X é que X seja 2*Cores, ou seja, duas threads por cada core. Daí me parecer que ele não tem uma máquina tão exótica a nível de processador (dois quad core) mas sim a nível de memória RAM.
Mas acho que o principal é mesmo ele meter o kernel monolítico e simplesmente com os drivers que ele sabe que usa.
O homem não compila o
O homem não compila o kernel para a 'maquineta' lá de casa. Recebe milhares de patches e alterações e é a partir daí que faz o lançamento de mais uma versão do kernel.
Já agora, alguma info acerca do desenvolvimento do kernel Linux em [1].
Esta info não está completa. As alterações têm sido 'exponenciais', o que quer dizer que o lançamento actual ainda tem muito mais alterações do que até à data desse documento.
Onde foste buscar isso do make?! O parâmetro das threads tem de ser indicado ao make com a opção -j.
O número de threads depende da arquitectura do processador, o meu suporta uma thread por core, mas por exemplo um 'Niagara' [2] suporta 8 threads por core.
1 - http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php
2 - http://www.sun.com/processors/UltraSPARC-T2/specs.xml
--
"No ínicio não havia nada e Ele disse: apt-get install light"
A thread específica[1] em
A thread específica[1] em que foi colocado o post do Linus tem um outro post dele a falar em:
Note that my "oldconfig" really only does the things I need, so this is
_not_ a "allmodconfig" or anything like that. That would take much longer.
It only has the drivers I use, and the stuff I actually need (it's not a
embedded kernel in any way, but it's definitely pared down config exactly
because I like being able to rebuild my kernels without wasting time on
thousands of drivers that I can't use anyway).
Daí a minha afirmação anterior.
Quanto ao make, sim eu disse que era com o parâmetro -j. E estive a ver que o mito que falei é apenas isso :) Acho que vem do tempo do p4 com HT em que apenas um processador podia processar duas threads ao mesmo tempo. Mas é como disseste, depende da arquitectura do processador. O core 2 duo por exemplo só processa uma única thread.
Mas por outro lado se colocarmos num core 2 duo o make -j 4 ele irá lançar 2 processos por cada core e enquanto um compila o outro poderá estar à espera de dados do disco. Não sei se na prática será ou não conveniente isto. Vou ver se faço algum teste simples.
[1] http://thread.gmane.org/gmane.comp.version-control.git/91001
Valendo o que vale :) Kernel
Valendo o que vale :)
Kernel 2.6.26.2
$ make -j 4
real 8m7.815s
user 14m19.190s
sys 1m24.569s
$ make -j 2
real 8m28.812s
user 13m59.460s
sys 1m22.129s
Para além destes valores com diferenças irrisórias, notei que com 4 jobs o processador era usado na maior parte do tempo ~100%, enquanto que com 2 jobs andava quase sempre pelos ~95%.
EDIT: Just for the record
EDIT: Just for the record (ramdisk)
$ mkdir ramdisk
$ mount -t tmpfs none ramdisk -o size=800m
$ sudo cp -R linux/ ramdisk/
$ cd ramdisk/linux
$ sudo make clean
$ sudo make -j 4
real 8m4.793s
user 14m14.893s
sys 1m21.093s
$ sudo make -j 2
real 8m36.997s
user 14m4.261s
sys 1m20.961s
O que me leva a pensar que o truque do Linus é mesmo ter uma grande besta a nível de processador :)
uma forma simples de o fazer
uma forma simples de o fazer é com um ramdisk, mas possivelmente podem(e devem) haver por ai uns truques...
Repara que ele compila apenas o que quer usar e num kernel monolitico.
::-------------------------------------
"Manage complexity, achieve agility"