Arquivos históricos do BR-Linux.org apresenta:

Boot do Linux em 0,2 segundos

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.

 

Comentários dos leitores
(Termos de Uso)

» darkside () em 29/09 23:18

Bem que as Distro's poderiam usar essas tecnicas para melhorar a velocidade do boot.


» Pierre () em 30/09 00:03

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á



» Douglas Augusto () em 30/09 00:56

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.


» liquidSLAVE () em 30/09 08:35

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



» Augusto Campos () em 30/09 09:55

É 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


» Peter Parker () em 30/09 10:07

Iniciando o X antes, o init correria em background? Ou a idéia de iniciar o X antes seria pra dispositivos embarcados/embutidos?


» Andre Celso () em 30/09 10:47

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.


» liquidSLAVE () em 30/09 10:57

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


» Carlos E. Morimoto () em 30/09 11:11


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.


» SlaveZero () em 30/09 11:17

Podiam traduzir esse artigo, aqui meu mandrake 9.1 está demorando mais tempo para carregar que o windows xp.


» djalmir () em 30/09 12:08

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.


» Augusto Campos () em 30/09 12:15

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.


» liquidSLAVE () em 30/09 12:39

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.


» EdCrypt () em 30/09 22:57

Legal! Só com os comentários já é possivel começar um tutorial novo! :)


» ofranja () em 30/09 23:44

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.


» Augusto Campos () em 30/09 23:55

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 ;-)


» ofranja () em 17/01 05:22

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.


» Augusto Campos () em 17/01 13:00

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.


» ofranja () em 13/05 01:49

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.



O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação, layout, tabela de caracteres, etc.) o acervo de notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter de acervo, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.