‘Bootando’ o Linux em cinco segundos

Na quinta-feira foi realizada a LPC (Linux Plumbers Conference, ou a Conferência dos Encanadores do Linux). Nela, Arjan van de Ven, desenvolvedor do Linux na Intel, e Auke Kok, autor do PowerTOP e também desenvolvedor do Linux no Centro de Tecnologia de Código Aberto da Intel, fizeram uma demonstração do boot de cinco segundos do Linux. O equipamento usado foi um Asus EEE PC com armazenamento em estado sólido. Os desenvolvedores atingiram a marca dos cinco segundos carregando dois softwares diferentes: o Fedora e o Moblin, ambos modificados. Eles tiveram que erguer o EEE PC para que o público pudesse ver alguma coisa, porque o sistema bootava antes que o projetor conseguisse exibir a imagem.

Como eles fizeram isso? Segundo Arjan, é uma questão de atitude. “A idéia não é bootar mais rápido, a idéia é bootar em cinco segundos.” Ao invés de ganhar um segundo aqui e outro ali, defina um cronograma para o sistema todo e faça com que cada etapa seja concluída no tempo determinado. E não vale trapacear. “Boot completo significa disco e o processador parados”, diz Arjan. Não vale abrir o desktop e continuar iniciando serviços nos bastidores (um membro da platéia acrescenta que a Microsoft faz isso). O tempo de boot não inclui a inicialização da rede, mas inclui a inicialização do NetworkManager. Um sistema com HD convencional leva mais tempo: Arjan disse que bootou o mesmo sistema em um ThinkPad em 10 segundos.

Em sua forma original, o Fedora leva 45 segundos desde o momento em que o computador é ligado até a tela de login do GDM. A ferramenta Bootchart, de Ziga Mahkovec, nos dá alguns detalhes. De acordo com um gráfico do Bootchart (figura 1), o Fedora parece desperdiçar tempo com algumas coisas. Ele leva um segundo para iniciar o dispositivo de loopback – verificando se todas as interfaces de rede do sistema são loopbacks. Depois leva dois segundos para iniciar o “sendmail.” “Todos pagam porque alguém quer rodar um servidor de email”, diz Arjan, sugerindo que para o caso de uso típico em um laptop – um servidor SMTP usado apenas para a saída de emails – é mais simples usar o ssmtp.

Figura 1: o Fedora 9 inicializa em 45 segundos, como vemos neste gráfico do Bootchart.

Outro processo que consome tempo no Fedora é o “setroubleshootd”, uma ferramenta útil para se descobrir problemas na configuração do Security Enhanced Linux (SELinux). Esse leva cinco segundos. Não se pode culpar o Fedora por tudo. Alguns projetos upstream também apresentam atrasos intrigantes. O X executa o pré-processador e o compilador C ao ser iniciado, para montar os mapeamentos de teclado.

O tempo de boot no Ubuntu é quase o mesmo: dois segundos mais rápido (figura 2). Ele passa 12 segundos rodando o modprobe, que no fim das contas carrega apenas um módulo. A ferramenta para adicionar drivers proprietários leva 2,5 segundos – em um sistema que nem precisa de drivers proprietários. “Todo mundo paga pelo driver proprietário”, diz Arjan. E o GDM do Ubuntu toma mais 2,5 segundos do tempo da CPU para exibir a imagem de fundo.

Figura 2: o Ubuntu é dois segundos mais veloz, mas perde tempo em tarefas diferentes.

As duas distribuições usam imagens durante o boot, conhecidas como splash screens. Arjan e Auke compartilham da mesma opinião: “Odiamos splash screens. Quando elas aparecem, já era para o sistema ter carregado.” O tempo de desenvolvimento que as distribuições gastam em splash screens é bem maior que o tempo gasto pela equipe da Intel para bootar o sistema rápido o bastante a ponto de não precisarmos delas.

Como eles conseguiram: o kernel

O primeiro passo foi estabelecer o cronograma. O kernel leva um segundo para inicializar, incluindo todos os módulos. O “pré-boot”, que inclui os scripts do init e as tarefas em segundo plano, leva mais um segundo. O X usa outro segundo, e o ambiente desktop usa dois.

O kernel deve ser compilado sem o initrd, que leva meio segundo sem nada nele. Ou seja, todos os módulos necessários para o boot devem ser compilados no kernel. “Com um punhado de módulos você cobre 95% dos laptops”, diz Arjan. Ele sugere a criação de uma imagem com o initrd para garantir os outros 5%.

Alguns ajustes no kernel permitiram a inicialização assíncrona de alguns subsistemas. Por exemplo, o kernel modificado inicializa a AHCI (Advanced Host Controller Interface) para lidar com o armazenamento ao mesmo tempo em que inicializa a UHCI (Universal Host Controller Interface) para lidar com o USB (figura 3). “É provável que possamos bootar o kernel em meio segundo, mas paramos em um segundo”, afirma Arjan. Ele acrescenta ainda que a inicialização do kernel deve cair para meio segundo no 2.6.28, graças a uma correção nova no suporte a AHCI.

Figura 3: a inicialização assíncrona do hardware mantém o tempo de boot do kernel em um segundo.

Outra mudança no kernel foi um pequeno patch para suportar o readahead. Agora o kernel registra quais blocos deve ler durante o boot e disponibiliza essas informações ao espaço de usuário quando o boot é concluído. Isso habilita o readahead, que é parte do processo de pré-boot.

Como eles conseguiram: readahead e init

O Fedora usa o Upstart como substituto ao histórico “init” que, tradicionalmente, é o primeiro programa executado em espaço de usuário. Mas a equipe da Intel voltou ao init original. A ordem das tarefas que ele gerencia foi modificada para que ele cuidasse de três coisas ao mesmo tempo: primeiro, de um processo “sReadahead”, que lê blocos do disco para armazená-los na memória; depois a etapa crítica: verificação do sistema de arquivos; por fim, o sistema de comunicação entre processos D-Bus, o X e o desktop. O terceiro grupo de programas a ser iniciado consiste no HAL (Hardware Abstraction Layer), no gerenciador udev para dispositivos hotplug, e na rede. O udev é usado apenas para suportar dispositivos que possam ser adicionados depois – o sistema tem um diretório /dev persistente para que o boot não dependa do udev.

O rearranjo das tarefas ajuda no uso eficiente da CPU. Por exemplo, o X atrasa meio segundo o carregamento de modos de vídeo, e é aí que o HAL realiza a inicialização que exige mais da CPU (figura 4).

Figura 4: o Readahead, a etapa crítica e outras tarefas sendo executadas ao mesmo tempo.

Em um gráfico de utilização do disco e da CPU, vemos que ambos estão em seu máximo durante o boot quase inteiro, graças ao sReadahead. Quando o X é iniciado, ele não precisa esperar para ler do disco, pois tudo já está no cache. O sReadahead é baseado no Readahead do Fedora, mas foi modificado para tirar vantagem da nova lista de blocos lidos do kernel. O sReadahead será lançado semana que vem no site moblin.org, e o patch para o kernel deve chegar ao público assim que Arjan acertar os detalhes com o mantenedor do sistema de arquivos ext3, Ted Ts’o (Ted estava na platéia, e deu algumas sugestões quanto ao reordenamento dos blocos do disco para aumentar ainda mais a velocidade do boot).

Há um limite de 75MB em leituras para o boot, definido pela velocidade máxima de transferência do armazenamento Flash: 3 segundos de I/O a 25MB/s. Por isso, “nós não lemos o arquivo inteiro. Lemos apenas os pedaços de arquivos de que precisamos”, diz Arjan. O sReadahead usa um agendamento de I/O “inativo”, de forma que se alguma coisa precisar do disco, pode aproveitá-lo. Desabilitando o readahead o sistema boota em sete segundos, mas com o readahead o objetivo de cinco segundos é atingido.

O X ainda é um problema. “Causamos sérias avarias ao X”, explica Arjan. Parte do trabalho implicou em cortar o carregamento do compilador C reutilizando mapeamentos de teclado, mas outras partes foram mais temporárias. A linha de desenvolvimento atual do X, no entanto, deixa mais da detecção e configuração do hardware para o kernel, o que deve diminuir ainda mais o tempo de inicialização. Como parte do tempo agendado pfara o kernel é gasto aguardando a inicialização do hardware, e como ele pode inicializar mais de uma coisa ao mesmo tempo, é mais eficiente usar o tempo do kernel para a inicialização do hardware do vídeo ao mesmo tempo em que ele cuida do USB e do ATA. Keith Packard, desenvolvedor do X que também trabalha na Intel, e que estava presente na platéia, ofereceu-se para ajudar. Configurar o modo de vídeo no kernel não permitiria que o kernel o inicializasse ao mesmo tempo que o resto do hardware, como vemos na figura 3. O sistema de boot rápido não usa o GDM, bootando direto em uma sessão de usuário do XFCE. Ao invés do GDM, como disse Arjan mais tarde, as distribuições poderiam entrar diretamente na sessão do último usuário e carregar o screensaver na mesma hora. Se outro usuário quisesse se logar, bastaria usar o botão para alternar usuário do screensaver.

Figura 5: um boot completo em 5 segundos. A inicialização é completada na marca de 5 segundos, quando o CPU e a atividade de E/S (I/O) finalizam e o sistema está pronto para uso.

Concluindo, Arjan disse: “Não se concentre em ‘bootar mais rápido’. A questão não é essa. A questão é ‘bootar rápido’.” E não faça os usuários esperarem porque umas poucas pessoas rodam o sendmail ou um sistema de arquivos que exige um módulo em seus laptops. “Faça de maneira que só pague o preço que usa o recurso.” Mais tarde, ele afirmou que as distribuições não deveriam ter que manter pacotes do kernel com e sem initrd. O kernel poderia tentar bootar sem o initrd, e voltar atrás caso não conseguisse enxergar o /sbin/init, como pode acontecer se estiver faltando um módulo necessário à montagem do sistema de arquivos raiz.

O PowerTOP gerou todo tipo de hack para a economia de energia em todas as áreas da cena de software do Linux. A união do Bootchart, do readahead e do objetivo de bootar em cinco segundos parece que vai dar origem a uma competição amigável pelo menor tempo de boot entre os adeptos do Linux. No sexta-feira, durante a conferência, Kyle McMartin anunciou que o Fedora e o Ubuntu já fixaram um cronograma para alguns atrasos do processo de boot, o que gerou muitos aplausos.

Créditos das imagens: Arjan van de Ven e Auke Kok, da Intel