Notícia publicada por brain em setembro 29, 2003 10:54 PM
| TrackBack
Este artigo do LinuxDevices descreve uma nova técnica que permite acelerar enormemente o boot do Linux: a versão atual da técnica dá o boot em 0,2s, e os autores pretendem chegar a 0,1s. Claro que não faz diferença para quem passa meses sem dar boot, ou para servidores cuja inicialização de serviços demora minutos. Mas em desktops (ainda mais somado à técnica deste outro artigo) pode ser interessante. E certamente é muito interessante no campo dos appliances e outras aplicações embedded, justamente o alvo da nova técnica.
Bem que as Distro's poderiam usar essas tecnicas para melhorar a velocidade do boot.
Quem passou a vida esperando o boot do WINDOWS, não reclamo das distribuições Linux, afinal espero não morrer antes do próximo boot.(risos), por isso não tenho tanta pressa.
Brincadeiras a parte, seria realmente interessante, eu por exemplo aprecio muito no slackware a velocidade do bot, pelo que vi a respeito ele usa o estilo BSD enquanto outras distribuições usam o estilo System V.
Estou certo ou falei besteira???
Entendi isso.
Um abraço a todos.
Pierre - Cuiabá
Acelerar o boot é muito importante, principalmente pelo "novo" campo que vem surgindo utilizando-se o Linux: os "auto-bootáveis", como games, vídeos, emuladores, etc.
Hoje já existem aplicações usando o Linux, por exemplo, para ter vídeos auto-inicializáveis, onde o tempo de boot é de suma relevância.
Nesse caso especifico o boot de 200 milisegundos eh do proprio kernel , ou seja , antes do init comecar.
Entao para quem usa uma distribuicao "regular" de linux nao muda muita coisa por enquanto. Agora se vc quiser brincar vc pode por exemplo substituir o comando init pelo XFree como comando padrao para o boot, por exemplo , no lilo :
image = /boot/bzImage
root = /dev/hda3
label = SuperLinux
append = "init=/usr/X11R6/bin/X
Com isso apos os 0,2 segundos de boot do kernel ele sobe o X. Claro que isso depende do tipo de compilacao que foi usada no X , a que eu sei que funciona se for feita dessa maneira eh o tinyXfree.
See Ya
É isso aí, liquidslave. Mas foi por esta mesma razão que eu coloquei aquele segundo link no texto, que leva a um artigo sobre como acelerar o init
Iniciando o X antes, o init correria em background? Ou a idéia de iniciar o X antes seria pra dispositivos embarcados/embutidos?
Normal... trabalhando o kernel, tirando oq vc nao necessita eh logico que vai bootar + rapido... mas como somos sedentos por coisas nossos linux sempre sobem milhoes de servicos... :D
Sure, pra appliances isso eh otimo, mas jah funcionam assim... e a maioria trabalha ao estilo BSD.
Peter ,
No caso do exemplo que eu citei nao rola init nenhum :)
Apos o auto-boot do kernel ele executa algum programa , qualquer um . Por padrao ele chama o init ou o rc no /sbin , /usr/sbin , /bin ,/usr/bin. Caso ele nao ache nenhum da kernel panic. Mas nada lhe impede de executar um hello-world binario ou qualquer programa que voce faca depois do boot do kernel.No exemplo que citei ele executa o X e soh o X , entao ele nao vai chamar o init , a nao ser que voce diga a ele para fazer isso.
"Linux , I love this game"
See Ya
Geralmente as distribuições carregam o KDM (ou GDM) no final do boot, você pode ganhar algum tempo inicando o serviço antes. Assim o boot normal continua em backgraund enquanto você já começa a ver o KDE carregando.
Podiam traduzir esse artigo, aqui meu mandrake 9.1 está demorando mais tempo para carregar que o windows xp.
existe algum tutorial em português de como acelerar o boot do linux? seria uma interessante aquisição para a área de tutoriais do site.
Não, André. Este artigo de hoje é sobre acelerar o boot do kernel, mesmo - antes de começar o init (só este último pode variar quando se opta pelo estilo sysv ou estilo bsd).
E o método deles não é simplesmente remover os módulos e subsistemas desnecessários. Eles realmente aceleraram até os necessários.
Mas tem um detalhe importante no caso do carregamento direto do *DM. Para que esse tipo de servico funcione corretamente ele nao pode ser carregado antes de meia duzia de servicos , jah que por exemplo a autenticacao pode depender do NIS , que por sua vez depende de outro carinha e etc. Algums desses servicos aumentam a seguranca e a confiabilidade do sistema , e perdem seu efeito profilatico ser forem carregados depois do servico X ou Y , por isso nao recomendo esse tipo de "tuning" em maquinas publicas ou de producao.
Legal! Só com os comentários já é possivel começar um tutorial novo! :)
Em qualquer empresa que preze a segurança, não é raro surgir a necessidade de atualização do kernel de alguma máquina, inclusive de algum servidor importante. E quanto mais tempo ele fica fora, pior. Agora me diga: Como que os servidores não vão tirar proveito desta técnica?
Indo mais além: Imagine aliando-se isso ao kexec.
Isso seria muito interessante, e posso falar por experiência própria: administro um servidor com uma interface SCSI da Adaptec (I2O RAID), e a dita cuja demora mais de 30 segundos pra inicializar.
Logo, isso seria de *MUITA* utilidade em servidores, mesmo aqueles que raramente são reinicializados (e que normalmente são aqueles que menos tempo devem ficar em downtime).
É isso.
ofranja:
na maior parte dos servidores que eu administro, o boot da bios e da interfgace scsi demora de 20s a 1min. Neles, reduzir o tempo de boot do kernel de 6 ou 7s para 1s (ou menos) faz pouquíssima diferença, por mais que o init também venha a ser enxugado - coisa que nem sempre dá de fazer em um servidor que precise inicializar vários serviços em sequência.
Onde dá, para aplicar, dá. Mas em alguns lugares a diferença é mesmo marginal.
Agora, se descobrirem como acelerar a inicialização da BIOS e da placa SCSI/RAID, a coisa muda de figura ;-)
Augusto: Por isso eu comentei sobre o kexec... Se você não conhece, é só procurar no google que você acha bastante documentação sobre esse patch.
É isso.
ofranja, mas não vejo como o kexec ou qualquer outra técnica aplicada sobre o boot ou o init possam reduzir o tempo de boot da bios ou dos devices. Eles podem retardar, postergar, reduzir a necessidade de reboot, etc - mas não vão acelerar o tempo de boot do hardware jamais.
Augusto:
Com o kexec, um tempo de boot mais demorado inevitavelmente vai ocorrer: quando se ligar a máquina pela primeira vez ou quando o micro for desligado. Entretanto, a magia do patch é eliminar a necessidade de se passar pela BIOS ao *rebootar* a máquina. Você boota de um kernel direto para outro kernel, e isso tudo evitando passar por detecções de RAIDs demorados, contagens de memória e outras coisas do estilo.
Supondo que seja possível acelerar o desligamento do sistema para 0,8 segundo, e associando a esta técnica de inicialização em 0,2 segundo, pode-se ter um sistema que reboota em 1 segundo. Isso é interessante, não? :-)
Bem, é isso.
Comentários desativados: Esta discussão é antiga e foi arquivada, não é mais possível enviar comentários adicionais.