Converter GiB para MiB

Um gibibyte são 1.073.741.824 bytes, cerca de 7 % a mais que um gigabyte. O Windows mede em gibibytes mas rotula «GB», e é nisso que consiste todo o mistério do espaço que some.

Um mebibyte são 1.024 kibibytes, ou seja 1.048.576 bytes. As ferramentas do Linux e os números de memória quase sempre se referem a isto, mesmo escrevendo «MB».

Neste sentido a conta é uma multiplicação, e por um número inteiro: um gibibyte são 1.024 mebibytes, exatamente, e 1.024 é a definição, não uma medição que chegou perto.

Isso faz dela uma das poucas conversões que valem de cabeça, e o resultado dá para conferir: divida de volta e você tem que cair no número de partida, exato e sem resto para explicar.

Um GiB são 1.024 da unidade de baixo; um GB, 1.000. Nesta página isso é a diferença entre 1024 MiB e 953,6743 MiB — 7,4 % — e a distância cresce a cada degrau: por isso é arredondamento desprezível numa foto e um pedaço visível de um HD.

O mistério do espaço que some é inteiro isso. Um disco vendido como um terabyte tem exatamente o que diz em unidades decimais; o Windows reconta em unidades binárias e mantém o nome decimal, então o número encolhe sem que nada tenha se perdido. O macOS conta em unidades decimais desde o 10.6, e é por isso que o mesmo disco pode aparecer com dois tamanhos em dois computadores.

O -m do QEMU é uma contagem de mebibytes pura. O virt-install recebe --memory em mebibytes. A maioria das APIs de nuvem e hipervisor escritas antes de os prefixos IEC terem nomes usam um campo chamado memoryMB, e o valor é binário independente do rótulo. Enquanto isso, todo catálogo de instâncias, plano de capacidade e documento de compra é escrito em gibibytes, então a conversão acontece exatamente no ponto em que um tamanho para de ser uma decisão e vira uma configuração.

O libvirt é a exceção que vale conhecer, porque seu XML de domínio define o elemento memory em kibibytes por padrão, não mebibytes. Um convidado de 8 GiB é <memory unit='KiB'>8388608</memory>, e um valor que parece um erro de digitação geralmente é a outra unidade. O elemento aceita um atributo unit explícito, e escrever unit='GiB' num template que humanos editam remove a dúvida permanentemente.

Um convidado com 8.192 MiB atribuídos custa ao host essa quantia para as próprias páginas do convidado mais um conjunto de estruturas que existem só porque a máquina é virtual. Tabelas de página aninhadas mapeiam guest-físico para host-físico e crescem com o espaço de endereços do convidado. O modelo de dispositivo roda como um processo do host com seu próprio heap. Memória de vídeo emulada é uma alocação real. O hipervisor mantém metadados por página para tudo que entrega.

O total costuma ser uma pequena porcentagem em vez de um número fixo, motivo pelo qual um host que rodava confortavelmente oito convidados de 8 GiB pode não rodar quatro de 16 GiB apesar de a aritmética ser idêntica. Dimensionar um host somando os mebibytes atribuídos e comparando contra a memória instalada não deixa nada para o próprio hipervisor, e a falha na ponta é o host trocando para disco (swap) — bem pior para um convidado do que receber menos memória logo de saída.

Memória de convidado geralmente é alocada no primeiro toque, então um convidado recém-iniciado com 16.384 MiB atribuídos pode estar consumindo um décimo disso no host. O driver de balão deixa o hipervisor recuperar mais: infla dentro do convidado, o kernel convidado libera páginas para satisfazê-lo, e o hipervisor as recupera. Desinflar as devolve. A cifra atribuída vira um teto em vez de uma reserva.

A consequência para a aritmética de capacidade é que há três números por convidado e só um deles está no arquivo de configuração. Atribuído é o que você digitou; o alvo do balão é o que o hipervisor permite agora; residente é o que o host de fato comprometeu. Um painel relatando qualquer um deles em gibibytes contra um plano construído sobre outro estará errado por um fator que muda ao longo do dia.

Apoiar um convidado com huge pages remove um nível de travessia de tabela de página e vale uma quantia mensurável em cargas pesadas de memória, mas muda a aritmética. Páginas viram 2 MiB em vez de 4 KiB, então a atribuição precisa ser um múltiplo de 2 MiB; o pool precisa ser reservado no host de antemão e não fica disponível para mais nada; e a alocação preguiçosa para, porque um convidado apoiado em huge pages recebe sua atribuição total imediatamente.

Isso transforma 8.192 MiB de teto em compromisso de 4.096 huge pages, e significa que overcommit está desligado para esse convidado. Também significa que o pool do host precisa ser dimensionado nas mesmas unidades: reservar 65.536 huge pages são 128 GiB, e um host que reserva mais do que seus convidados usam tirou essa memória de tudo mais. Onde um convidado usa huge pages de 1 GiB, a atribuição precisa ser múltiplo de 1.024 MiB, e a granularidade de qualquer erro é um gibibyte inteiro.

Num host com mais de um nó de memória, um convidado maior que um nó precisa ser dividido, e a divisão é muito melhor feita deliberadamente do que deixada ao escalonador. Um convidado de 12.288 MiB em dois nós dá 6.144 cada, o que é arrumado; o mesmo convidado a 12.000 MiB dá 6.000 cada, aritmeticamente correto e incômodo contra huge pages e contra qualquer reserva por nó.

A falha quando isso fica implícito é acesso remoto à memória: uma CPU virtual fixada num nó lendo páginas que moram no outro paga uma penalidade de latência a cada acesso, e o efeito é uma carga mais lenta que o mesmo convidado num host menor. O virsh numatune e a própria topologia NUMA do convidado importam, e os dois são configurados em mebibytes por nó, então a cifra em gibibytes precisa dividir de forma limpa antes de qualquer um deles ser expresso.

Somar mebibytes atribuídos entre convidados e dividir pela memória do host dá uma razão de overcommit, e razões até cerca de 1,5 são rotina em cargas com convidados ociosos. O motivo de funcionar é que atribuído é um teto e a maioria dos convidados nunca se aproxima dele. O motivo de falhar é que os convidados que se aproximam tendem a fazer isso ao mesmo tempo, porque geralmente estão respondendo ao mesmo evento.

O número que vale acompanhar junto da razão é a memória livre do host em mebibytes no pico, não na média, e o que evitar é o host recorrer a swap. Um convidado cujas páginas são trocadas pelo host experimenta isso como memória que ficou mil vezes mais lenta sem indicação do porquê, e o próprio gerenciamento de memória do convidado — que acredita que essas páginas são RAM — vai tomar exatamente as decisões erradas sobre elas.

Hotplug de memória não acrescenta quantidades arbitrárias. O convidado expõe um tamanho de bloco — comumente 128 MiB em x86-64 — e memória chega em blocos inteiros, então um pedido de 1.000 MiB vira oito blocos e 1.024 MiB. Remoção é mais difícil que adição, porque o kernel convidado precisa esvaziar o bloco primeiro e pode não conseguir se algo não-movível caiu nele. Um convidado que cresceu de 4 GiB para 12 pode não voltar a encolher.

A abordagem prática é dimensionar para o conjunto de trabalho com a folga que a carga merece, e tratar redução como um reinício em vez de uma operação online. Onde um convidado genuinamente precisa variar, o balão é o mecanismo que lida bem com isso, e o hotplug é o que lida com crescimento além do teto original — e o próprio teto, a cifra maxMemory, é outro campo em mebibytes que precisa ser definido antes de o convidado iniciar.