Descompactar o initramfs é muito lento

Question

Estou tentando melhorar o tempo de inicialização do kernel do meu dispositivo e gostaria de receber ajuda. Eu estou usando OMAPL138 com a versão do kernel 2.6.37 e leva cerca de 50 segundos até que o processo de inicialização seja concluído, e eu acho que é um longo tempo. Abaixo está a imagem de alguns estágios do processo de inicialização. Como você pode ver, há um atraso de 19 segundos até que a mensagem apareça e acho que esse é o principal problema do meu tempo de inicialização.

Após alguns testes, descobri que esse atraso ocorre durante a descompactação do initramfs.cpio.lzma . Descobri isso imprimindo algumas mensagens no arquivo initramfs.c , e esse atraso acontece no loop while dentro da função unpack_to_rootfs . O initramfs.cpio.lzma tem 5,3MB e a imagem total do kernel (uImage) tem 7,3MB.

Minha pergunta é: estou fazendo algo errado ou a única maneira de melhorar isso é reduzindo o tamanho do meu kernel? Talvez alguns de vocês tenham tido que lidar com esse problema antes, então eu gostaria de algumas sugestões sobre como proceder para melhorar meu tempo de inicialização. Muito obrigado.

    

Answer 1

Possivelmente não é um afunilamento da CPU, mas um tempo de acesso lento à mídia flash? Encontrei este tópico abaixo nos fóruns de TI falando sobre a taxa de transferência do flash limitada a 0,6 MB / s. OMAP-L138 EVM Desempenho de leitura do SPI Flash e tempo de inicialização

Para um teste (como sugerido por Janus), veja se você pode compactar uma imagem do kernel e / ou o initramfs com gzip -0 , se possível. Ou pode ser mais simples (em outra estação de trabalho), obter uma cópia do arquivo initramfs.cpio.lzma , descompactá-lo para initramfs.cpio e recompactar com lzma -0 . Sobrescreva o novo arquivo recomprimido de volta para a mídia flash. Espero que o arquivo seja um pouco maior. Se inicializar mais rápido, provavelmente a CPU era um gargalo. Se for iniciado mais lentamente, provavelmente o IO foi o gargalo.

Talvez até repita o teste com lzma -9 , mas cuidado, pois pode exigir muita memória para compactação e descompactação.

Aqui está um trecho da página do manual lzma (v5.07):

     On the same hardware, the decompression speed is approximately
     a constant number of bytes of compressed data per second.   In
     other words, the better the compression, the faster the decom-
     pression will usually be.  This also means that the amount  of
     uncompressed output produced per second can vary a lot.

     The following table summarises the features of the presets:

            Preset   DictSize   CompCPU   CompMem   DecMem
              -0     256 KiB       0        3 MiB    1 MiB
              -1       1 MiB       1        9 MiB    2 MiB
              -2       2 MiB       2       17 MiB    3 MiB
              -3       4 MiB       3       32 MiB    5 MiB
              -4       4 MiB       4       48 MiB    5 MiB
              -5       8 MiB       5       94 MiB    9 MiB
              -6       8 MiB       6       94 MiB    9 MiB
              -7      16 MiB       6      186 MiB   17 MiB
              -8      32 MiB       6      370 MiB   33 MiB
              -9      64 MiB       6      674 MiB   65 MiB

    

Answer 2

Se a velocidade de IO não é o gargalo, outra opção é usar a compactação LZ4, o que dá aos arquivos um pouco maior que o gzip, mas a descompressão é extremamente rápida.

A opção de configuração do kernel para compactar o kernel com isto é CONFIG_KERNEL_LZ4 = y.

link