kernels diferentes relatam quantidades diferentes de memória total na mesma máquina

Question

Eu tenho dois kernels x86_64 compilados na mesma máquina com o mesmo código (4.15.0 em árvore de fontes do Linus ).

Os arquivos de configuração foram produzidos rodando make localmodconfig naquela fonte, usando diferentes arquivos de configuração originais vindos de diferentes distros: Arch e Slackware, respectivamente. Eu vou apelidá-los

arch config

e

slk config

por esse motivo.

O problema: a execução de cat /proc/meminfo informa consistentemente mais de 55 a 60 MB no campo MemTotal para arco do que para slk :

MemTotal: 32600808 kB para arco

vs

MemTotal: 32544992 kB para slk

Eu digo 'consistentemente' porque eu experimentei o experimento com os mesmos arquivos de configuração contra versões anteriores da fonte (um monte de kernels 4.15-rc, 4.14 antes disso, etc., rolando de uma fonte para outra próximo com make oldconfig ).

Isso se reflete nos números relatados pelo htop, com slk relatando ~ 60MB a menos de uso na inicialização do que arco . Isso é consistente com a explicação do htop dev como os números de memória usados do htop são baseados em MemTotal .

A minha pergunta é: quaisquer sugestões para quais opções de configuração eu deveria olhar que fariam a diferença?

Eu, claro, não me importo com os 60MB (a máquina que os kernels rodam tem 32GB ..), mas é um quebra-cabeça interessante para mim e eu gostaria de usá-lo como uma oportunidade de aprendizado.

O relatório de memória no Linux é discutido intensamente nesses fóruns e fora em geral, mas a busca por esse tipo específico de problema (diferentes kernels / same machine = > resultado diferente no relatório de memória) não produziu nada que eu considerasse relevante.

Editar

De acordo com as sugestões na postagem vinculadas por @ErikF, eu dei uma olhada na saída de

journalctl --boot=#

onde # significa 0 ou -1, para as inicializações atual e anterior, respectivamente (correspondendo aos dois kernels). Essas linhas parecem refletir a diferença, então agora é um pouco mais claro para mim de onde vem:

arch (aquele que relata MemTotal maior):

Memória: 32587752K / 33472072K disponível (código do kernel 10252K, 1157K rwdata, 2760K rodata, 1364K init, 988K bss, 884320K reservados, 0K cma-reserved)

slk (o que relata MemTotal menor):

Memória: 32533996K / 33472072K disponível (código do kernel 14348K, 1674K rwdata, 3976K rodata, 1616K init, 784K bss, 938076K reservado, 0K cma-reserved)

Essa é uma diferença de ~ 55 MB, como esperado!

Eu sei que o kernel slk é maior, como verificado comparando os tamanhos dos dois arquivos vmlinuz em minha pasta / boot /, mas o peso da diferença parece vir de quanta memória dois respectivos reservatórios de sementes.

Eu gostaria de entender melhor o que nos arquivos de configuração afeta que , na medida em que isso acontece, mas isso certamente lança alguma luz.

Segunda edição

Respondendo as perguntas no comentário de @Tim Kennedy.

Do you have a dedicated GPU, or use shared video memory

Nenhuma GPU dedicada; é um laptop com gráficos Intel integrados.

and do both kernels load the same graphics driver?

Sim, i915.

Also, compare the output of dmesg | grep BIOS-e820 | grep reserved

Como você esperava, não muda. Em todos os casos, são 12 linhas, idênticas em todos os aspectos (endereços de memória e tudo).

(Final?) editar

Eu acredito que pode ser tão simples assim: o kernel reportando menos MemTotal tem muito mais do conjunto de drivers embutido; Eu só não tinha percebido que isso faria uma diferença tão notável ..

Eu comparei:

du -sh /lib/modules/<smaller-kernel>/modules.builtin

retorna 4K, enquanto

du -sh /lib/modules/<larger-kernel>/modules.builtin

retorna 16K.

Então, no final, acredito que estava latindo na árvore errada: não será uma única opção de configuração (ou um punhado), mas sim o efeito acumulado de muitos outros drivers internos.

    

Answer 1

Eu acredito que a imagem é como na minha última edição acima; Eu simplesmente não sabia o suficiente sobre o processo de reservar memória para perceber quando fiz a pergunta: tudo se resumia ao kernel maior com mais drivers embutidos em vez de modularizados.

Incidentalmente, eu queria colocar isso em algum uso prático (remotamente): Eu queria ter um kernel tão fino quanto pudesse, mas ainda inicializá-lo sem um initrd. Eu sabia que

• o kernel menor (moniker arch acima) é muito leve e rápido para inicializar, mas não sem um initramfs;

• o kernel maior ( slk ) irá arrancar sem um initramfs, mas demora mais tempo.

Então eu fiz um compromisso que acho que vou continuar por agora. Peguei os dois arquivos de configuração, chamo-os de large e small e garantimos que todas as opções de configuração unset em small sejam refletidas em grande .

Primeiro,

awk '/^# CO/ {print} small > staging'

pega todas as linhas no arquivo de configuração small que estão na forma

# CONFIG_BLAH is not set

e os despeja em um arquivo de texto staging . Então,

for i in $(awk '{print $2}' staging) ; do sed -i "s/^$i=./# $i is not set/" large ; done

usa todas as linhas do arquivo de configuração large que definem (via =y ou =m ) uma opção contida em staging e as desativa.

Em seguida, executei make oldconfig no arquivo resultante large no diretório de origem do kernel e compilado. Tudo correu bem:

• o novo kernel inicializa cerca de 3 segundos mais rápido

• sem um initramfs

• é muito menor no sentido de que seu /lib/modules/<kernel>/modules.builtin foi reduzido pela metade, de 16K para 8K.

Não há muito o que escrever, mas, como eu disse, isso me intrigou. Acho que estou decidido agora.

Presumivelmente, a coisa mais direta a fazer teria sido descobrir de uma vez por todas precisamente quais drivers eu preciso nesta máquina para poder inicializar sem um initramfs, mas deixarei isso para Algum outro dia. Além disso, jogar uma configuração contra a outra era um exercício divertido por si só.